Check that whatever it is you try to include really exists...
GCC has no problems with two updirs (or three or four or whatever).
#include "mylib.h"
-------------- Build: Win32 Debug in gcctest ---------------
Compiling: .\mylib\src\mylib.c
Linking console executable: C:\test\gcctest\Debug\gcctest.exe
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
It certainly does. It compiles in MSVC.It is not as certain as you think.
After adding the include directories, I had to modify...
In the project which you supplied...there are no include directory settings at all
This is on purpose.Well, on purpose or not, it's wrong ;)
But, perhaps moving to gcc just requires adding include directories (adding gazillions of include directories if you have gazillions of subprojects) ??
After adding the include directories, I had to modify...
Sorry, buy this (gcctest.zip) is a perfectly valid project as is, I believe.
The idea is to not change anything. Especially not the source files.
#include "./mylib/include/mylib.h"
CodeThe problem is when you give a relative path: from where begin the search?#include "./mylib/include/mylib.h"
This is on purpose.Well, on purpose or not, it's wrong ;)
CodeThe problem is when you give a relative path: from where begin the search?#include "./mylib/include/mylib.h"
I believe it's fairly clear, apostrophes ("") means 'here' (the location of the .c file with the #include in it), lessthan-greaterthan (<>) means search include paths (first). But I could be wrong I guess.
The problem is when you give a relative path: from where begin the search?Spot on.
...apparently it looks in the directory it was invoked from...but NOT the directory the file being compiled is in
Cklo
|- Source
|- Engine
| |- Engine.cpp {#include "../base.h"}
|- base.h
Now that I've posted all that, I'm not so sure anymore
Excellent! Thanks TDragon!And thanks to Michael,Thomas and Mandrav too!
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
For now, you would probably need to add all your source subdirectories...
Interesting :).
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 :)).
I can afford to wait - a while yet :)You'd have to; even if the bug is fixed in the current version of GCC...
Interesting :).
it is because gcc is executed from the project directory (where the *.cbp resides) and all pathes are relative to this directory.
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)
Oh, but I have a feeling that this is a C::B bug (rightclick -> "Build File" works), not a GCC bug.
it is not a CB bug...rightclick works, because gcc is executed in the directory where the source file resides...
"...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.
Really, there is no reason to react like that...
...you can always add/fix it yourself.
...the fix has been committed.
Thomas just closed (threw out) my 'bug' report:You see, several people already told you. It is not a bug, neither in the IDE, nor in the compiler. You are not using the tools properly.
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).
Although I refuse to consider this as a bug but rather lack of configuration from the user's part, the fix has been committed.Now we do have a bug... :?
[ ] Add Extra search paths like MS-VisualStudio (WARNING: NOT recommended for cross-platform projects since it's not ISO-C++ compliant)
Forgive my ignorance, but perhaps there is a different approach...That's not ignorance at all. That's the correct way :)
Why couldn't the MS project/workspace import do the work and add the required paths to the job file? While I realize this may be more work and may raise other issues, it would seem to be a less offensive approach to the core C::B design.
Because it is not right to add a path secretly. Although it will probably (hopefully) never cause a problem in this particular case, it still is not right. You don't know where it is inserted (first, last...?) either. Well, you would know if you looked at the sources, but the point is you don't even know that it is happening.
The correct way of operation for a compiler is to have a clearly defined set of search paths (and a clearly defined order), so there is no question about which one to use.
The compiler should...not perform any MS-style capers.
The sentence you quoted from the website, does not mean that we 'll work for any crazy idea anyone might have. And for free.
I agree with Thomas on this. We should not add secretely extra paths, to get something to compile.
I agree with Thomas on this. We should not add secretely extra paths, to get something to compile.
* Added compiler-independent option to explicitely add the currently compiling file's directory to the compiler's search dirs
Autotools do change the working dir to the file's dir also, like MSVC
After a good long time to think I cannot think of any reason not to do it like autotools and MSVC.
In other words, how about removing this option? Just make the default to change the dir to the compiling file's dir when compiling. This seems natural and would bring CB in step with the other tools.
cd WhereTheFileIs/file.cpp
gcc file.cppgcc -IWhereTheFileIs file.cppSo now I understand, it's aboutCodeinstead ofcd WhereTheFileIs/file.cpp
gcc file.cppCoderight?gcc -IWhereTheFileIs file.cpp
gcc -IWhereTheFileIs file.cppcd WhereTheFileIs
gcc file.cppMaybe this option can be removed againAs long as old compilers are in th use we shouldn't remove it. Its disabled by default and... well... "well hidden" so it should not harm. And anyways: If you enable it it won't cause any negative side-effects even if MinGW add it once again.