Moving to GCC question

[troels]

Now that I've posted all that, I'm not so sure anymore

I'm quite sure. My projects also compiles one updir (#include "..") for some reason, it breaks only on two ("../../").
(Again, rightclick -> "Build File" works, Ctrl+F9 doesn't)

Excellent! Thanks TDragon!

And thanks to Michael,Thomas and Mandrav too!

/Troels

[TDragon]

Ah, now that's an interesting gotcha. Probably deserving of a bug report to GCC if someone can get rigorous on it. For now, you would probably need to add all your source subdirectories under Code::Blocks' Project->Build Options->Directories->Compiler, to avoid making changes to the actual source files.

[tiwag]

Here's a little test C::B project for demonstrating this:
http://www.trak.dk/gcctest.zip

add a Compiler directory "./mylib/src"

because all your relative pathes are relative to that dir

then it works

[attachment deleted by admin]

[Michael]

add a Compiler directory "./mylib/src"

because all your relative pathes are relative to that dir

then it works

Interesting .

Michael

[troels]

For now, you would probably need to add all your source subdirectories...

Been down that route. Not really feasible in largish projects. I can afford to wait - a while yet

/Troels

[tiwag]

Interesting .

it is because gcc is executed from the project directory (where the *.cbp resides) and all pathes are relative to this directory.

so

"./mylib/src"  + "../include/mylib.h"

and

"./mylib/src"  + "../../mylib/include/mylib.h"

are ok then

[TDragon]

I can afford to wait - a while yet

You'd have to; even if the bug is fixed in the current version of GCC, it'll probably still be months before the MinGW team gets to it. I've never personally seen problems with search paths in the larger GCC projects I've worked on (witness Code::Blocks .

[troels]

I can afford to wait - a while yet

You'd have to; even if the bug is fixed in the current version of GCC...

Oh, but I have a feeling that this is a C::B bug (rightclick -> "Build File" works), not a GCC bug.
And they work fast here on this project
(I can't believe that you've already moved to wxAUI, that was bloody fast)

Regards
Troels

[Michael]

Interesting .

it is because gcc is executed from the project directory (where the *.cbp resides) and all pathes are relative to this directory.

Yes, I have remarked it. My solution would have been to add the 2 include directories in Compiler (relative paths) and then modifiy/add the #include opportunely. Your solution is shorter and avoid to add all the include directories. Thank you for the explanation.

Michael

[Michael]

I can afford to wait - a while yet

You'd have to; even if the bug is fixed in the current version of GCC...

(rightclick -> "Build File" works)

In this case is not the compiler invoked from the directory where the source file is? And, if I remember correctly, the include paths are then correct.

Michael

[tiwag]

Oh, but I have a feeling that this is a C::B bug (rightclick -> "Build File" works), not a GCC bug.

1. it is not a CB bug, CB is working 100% properly - see your project definitions
2. rightclick works, because gcc is executed in the directory where the source file resides also the *.o file is produced there.
3. add the compiler include directory(ies) properly and everything is fine.

[troels]

it is not a CB bug...rightclick works, because gcc is executed in the directory where the source file resides...

I realized that a while back:

http://sourceforge.net/tracker/index.php?func=detail&aid=1409127&group_id=126998&atid=707416

/Troels

[troels]

Thomas just closed (threw out) my 'bug' report:
https://sourceforge.net/tracker/?func=detail&atid=707416&aid=1409127&group_id=126998

"...IDE built specifically to meet the most demanding needs of its users"

Guess I'm too demanding then. I need my IDE/compiler to be fairly compatible with other compilers (MS).
C::B + MinGW comes so close.

Here's my 'bug' report again for posterity:

"
#include with quotes doesn't work for relative paths

#include "../../foo.h" does not compile in C::B.

In many cases this effectively prevents a clean compile
after importing a MSVC project/workspace, see
TDragons's (first) reply:
http://forums.codeblocks.org/index.php?topic=2039

I propose compiling in the source file directory (where
the .c/cpp file is located), rather than in the .cbp
directory.

If this breaks (too) many things, please consider this
a feature request:

A compile option (checkbox) such as "Compile this file
inplace (where the .c/cpp file is located)" would be
useful."

Regards
Troels

EDIT:
Notes:
- Adding include paths to everything and the kitchen sink is impractical, makes for (even) slower compilations, makes moving to C::B more of a hassle than necessary
- This particular problem might very well be considered a bug in/shortcoming of gcc, but still, I believe that the job of the IDE is to shield the user from (most) antics of compiler X, to take the drudgery out of software development.

[mandrav]

"...IDE built specifically to meet the most demanding needs of its users"

Guess I'm too demanding then. I need my IDE/compiler to be fairly compatible with other compilers (MS).
C::B + MinGW comes so close.

The sentence you quoted from the website, does not mean that we 'll work for any crazy idea anyone might have. And for free. But you can always add/fix it yourself.

It's really sad when people show no respect at other people's hard work (free as in beer and in speech)...
Really, there is no reason to react like that...

EDIT:
Although I refuse to consider this as a bug but rather lack of configuration from the user's part, the fix has been committed.

[troels]

Really, there is no reason to react like that...

Sorry then.

...you can always add/fix it yourself.

It would have to be acknowledged as a good idea first. Thomas simply discarded the 'bug' report, which could lead one to believe that the idea was unpopular with the devs here (wait for gcc itself to be fixed), hence unwanted. Not everybody have a long history with gcc, and gcc frontends, and knows exactly what to expect from it and not.

...the fix has been committed.

Quite a surprise. Amazing!

/Troels