User forums > General (but related to Code::Blocks)
Moving to GCC question
tiwag:
--- Quote from: troels on January 18, 2006, 05:17:54 pm ---Oh, but I have a feeling that this is a C::B bug (rightclick -> "Build File" works), not a GCC bug.
--- End quote ---
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:
--- Quote from: tiwag on January 18, 2006, 05:24:13 pm ---it is not a CB bug...rightclick works, because gcc is executed in the directory where the source file resides...
--- End quote ---
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:
--- Quote ---"...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.
--- End quote ---
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:
--- Quote from: mandrav on January 19, 2006, 03:24:53 pm ---Really, there is no reason to react like that...
--- End quote ---
Sorry then.
--- Quote from: mandrav on January 19, 2006, 03:24:53 pm ---...you can always add/fix it yourself.
--- End quote ---
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.
--- Quote from: mandrav on January 19, 2006, 03:24:53 pm ---...the fix has been committed.
--- End quote ---
Quite a surprise. Amazing!
/Troels
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version