Re: .cch => {.cc, .h}
Re: .cch => {.cc, .h}
- Subject: Re: .cch => {.cc, .h}
- From: "Oscar Stiffelman" <email@hidden>
- Date: Wed, 14 Feb 2007 04:58:29 -0800
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
_______________________________________________
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