Re: .cch => {.cc, .h}
Re: .cch => {.cc, .h}
- Subject: Re: .cch => {.cc, .h}
- From: "Oscar Stiffelman" <email@hidden>
- Date: Thu, 15 Feb 2007 15:28:54 -0800
I've been thinking more about this approach. It certainly breaks
fix+continue since .o's are no longer 1-to-1 associated with source
code. In addition, it would result in significant repetition of
assembly code, one copy per compilation unit that references a
function. The linker might be able to reduce some of this redundancy,
but it seems like a significant responsibility for the linker. I
would rather push the complexity to the tool-chain, but I don't know
if the tool-chain is up to the task.
I think STL does this because it really wants the methods inline for
performance, and also it needs to be in .h's because the templates get
instantiated at compile time, not link time.
To summarize, there are a few issues I am trying to solve. First, I
need the build system to work in this "unified .h/.cc" world. I'm
pretty sure I can solve those problems using build rules. Second, I'm
trying to get xcodeindex to understand the code structure. The main
impediment to that is that xcodeindex doesn't know where to find the
autogenerated .h files (it doesn't have an includepath that I can
modify).
I wish Apple would document how xcodeindex works, and provide a way to
make it work in more configurations. I don't want to start a
flame-war, but this is a clear example where open-source wins-- I
should be able to just look at the code and see how this critical
component works, and possibly add functionality to make it better.
On 2/14/07, Steve Baxter <email@hidden> wrote:
Hi Oscar,
I would have thought that you wouldn't want the inline functions in
your .o files - you want them to be inline! Larger functions won't
be inlined anyway even if they are declared in the headers.
This is exactly the approach that STL takes - pretty much everything
is in headers.
Cheers,
Steve
On 14 Feb 2007, at 12:58, Oscar Stiffelman wrote:
> Steve,
>
> It's an appealing idea, but I think it doesn't work because when gcc
> compiles a .cc file with inline methods, it doesn't include the inline
> methods in the .o files. You can disable this with a flag
> (-fkeep-inline-functions), but then it expands the .o by > 100x in my
> simple test cases (I tried this a few days ago just to see if this was
> a feasible approach) because it applies to everything, including
> system libraries that get included.
>
> Thanks,
>
> -O
>
> On 2/14/07, Steve Baxter <email@hidden> wrote:
>> Hi Oscar,
>>
>> If you want to work this way, why not just leave all your code inline
>> in the .cch (or .h) file rather than trying to generate a .h and .cc
>> file at compile time? You would need one .cpp file (probably main or
>> some equivalent).
>>
>> Cheers,
>>
>> Steve
>>
>> On 12 Feb 2007, at 23:16, Oscar Stiffelman wrote:
>>
>> > Xcode Community:
>> >
>> > I don't like maintaining .cc and redundant .h files. Instead, I do
>> > this (It's easiest to just show an example):
>> >
>> > in file "foo.cch"
>> >
>> > class Foo {
>> > public:
>> > void doSomething() {
>> > // actual code here, inline in the class
>> > }
>> > };
>> >
>> > At build time, I use a program to convert this to:
>> >
>> > file "foo.cc"
>> > #include "foo.h"
>> > void Foo::doSomething() {
>> > // same code as before
>> > }
>> >
>> >
>> > file "foo.h"
>> > #ifndef FOO_H
>> > class Foo {
>> > public:
>> > void doSomething(); // just the declaration
>> > };
>> > #endif FOO_H
>> >
>> >
>> >
>> > I'm trying to determine if this approach will work in the Xcode
>> world
>> > (I've been doing this on linux for a while using my own build
>> system,
>> > and I find it much more productive and pleasant than the
>> traditional
>> > approach).
>> >
>> > Here are the issues I've encountered so far:
>> >
>> > - Xcode doesn't know that .cch files are just c++ files. I
>> > experimented with a .pbfilespec, and managed to tell Xcode
>> that .cch
>> > was just a c++ file. That fixed syntax coloring, but none of the
>> > symbols appear in the "Project Symbols" view.
>> > Possible workaround: If I rename these files to .cpp, then they
>> are
>> > indexed in Project Symbols. Are there other solutions?
>> >
>> > - xcodeindex doesn't find my include files
>> > For discussion, assume this set of input files (all relative to $
>> > (PROJECT_DIR))
>> > x/y/z/Foo.cpp
>> > x/y/z/Bar.cpp
>> > genfiles/x/y/z/Foo.h (not actually added to the project)
>> >
>> > and Bar.cpp contains the line
>> > #include "x/y/z/Foo.h"
>> >
>> > Even if I add "genfiles" to the "Header Search Paths" in the
>> project
>> > settings, xcodeindex never finds the file. I have issued
>> xcodeindex
>> > -loglevel 6 from the command line, and it clearly ignores the
>> "Header
>> > Search Paths," complaining that it is unable to locate x/y/z/Foo.h.
>> > Is there a way to add include paths so that xcodeindex can find
>> these
>> > files? I'm pretty sure that "Header Search Paths" is just used at
>> > build time. I tried adding the genfiles directory to the
>> project, and
>> > that didn't solve the problem.
>> >
>> > - I managed to build {.cc,.h} by adding a build rule that matches
>> > .cpp, and lists the {.cc,.h} as output files. I was surprised that
>> > this (mostly) just worked. The only problem I encountered was I
>> > couldn't access the relative path when defining the output file for
>> > the build rule.
>> > If the input file is: x/y/z/Foo.cpp
>> > I want the output files to be: {genfiles/x/y/z/Foo.h, genfiles/x/y/
>> > z/Foo.cc}
>> > But I can't assemble those names from any of the variables.
>> > $(SCRIPT_INPUT_FILE) is the absolute path
>> > $(INPUT_FILE_NAME) has zero path information ... just Foo.cpp
>> > I want to say:
>> > $(PROJECT_DIR)/genfiles/$(RELATIVE_DIR)/$(INPUT_FILE_BASE).cc
>> > $(PROJECT_DIR)/genfiles/$(RELATIVE_DIR)/$(INPUT_FILE_BASE).h
>> >
>> > but $(RELATIVE_DIR) doesn't exist as a variable.
>> > My workaround:
>> >
>> > $(PROJECT_DIR)/genfiles/$(INPUT_FILE_DIR)/$(INPUT_FILE_BASE).cc
>> > $(PROJECT_DIR)/genfiles/$(INPUT_FILE_DIR)/$(INPUT_FILE_BASE).h
>> >
>> > The problem with this is it expands to:
>> > /Users/me/src/genfiles/Users/me/src/x/y/z/Foo.cc
>> > /Users/me/src/genfiles/Users/me/src/x/y/z/Foo.h
>> > I wanted to preserve the original directory structure, but
>> relocated
>> > under genfiles. This sort of solves the problem, but it's not
>> exactly
>> > what I wanted b/c it adds the redundant '/Users/me/src'.
>> >
>> >
>> > - ZeroLink and Fix+Continue
>> > My derived files use the standard preprocessor "#line linenum
>> > filename"
>> > This means that if gcc encounters an error during compilation of
>> > genfiles/Foo.cc, it will be reported in terms of the original
>> source
>> > file, Foo.cpp (as per above note, this used to be called
>> Foo.cch to
>> > make it clear that it was the source, and the .cc,.h were the
>> derived,
>> > but xcode doesn't index .cch files). In addition, the debugger
>> > properly shows the original source file, and not the derived source
>> > file.
>> > if I modify Foo.cpp during a debug session, and try to use "Fix and
>> > Continue", it correctly triggers the build rule for the original
>> > source file. But it doesn't compile the derived file, or try to
>> link
>> > in the derived .o.
>> >
>> > I am new to Xcode, and I have only mentioned the issues I have
>> > encountered so far. I would be very grateful if people would
>> comment
>> > on these specific issues, or on issues I may encounter in the
>> future
>> > if I keep trying to use this approach in Xcode. Does using
>> the .cch
>> > approach mean that I will not be able to take advantage of
>> significant
>> > productivity features offered by Xcode? I am willing to
>> abandon .cch,
>> > but only after I have explored the possibility of having both.
>> >
>> > Thanks in advance,
>> >
>> > Oscar
>> > _______________________________________________
>> > Do not post admin requests to the list. They will be ignored.
>> > Xcode-users mailing list (email@hidden)
>> > Help/Unsubscribe/Update your Subscription:
>> > 40improvision.com
>> >
>> > This email sent to email@hidden
>>
>> Steve Baxter
>> Software Development Manager
>> Improvision
>> +44-2476-692229
>>
Steve Baxter
Software Development Manager
Improvision
+44-2476-692229
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden