Moving to GCC question

[thomas]

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).

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.

A compiler is not a divination apparatus, and neither is an IDE. If you put your files into some folder, then the compiler won't know unless you tell it.
Maybe Visual Studio does that differently (maybe they have the search path ../include built-in, I don't know), but this is not standard, and it is not correct.

The reason why the compiler does not scan large portions of your hard disk and use whatever files it can find is that you may have many different headers with the same name (for example there is a file string.h in the wxWidgets headers and a file with the same name in the system headers. You might even have a file with that same name too, although that would be bad design).
If the compiler just looked in arbitrary places and use whatever it happens to find, you would have a terrible mess every time.

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.

Consequently, the correct way of operation for you is to tell the compiler what you want. If you don't do that, the compiler will not work properly.

[thomas]

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...  :?

[tiwag]

@thomas : why do you think it's a bug, when CB adds the module's path to the compiler's include directories by default

[thomas]

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.

If we start adding paths, then why don't we add ./include, ../include, and ../../include too? We might add ../src/include and ../source/include as well, then the people who put their project files in some subfolder would be happy.

Following the same reasoning, we could secretly add -lkernel32 to the linker options under Windows because practically all Windows applications need that anyway. Does really anybody think this would be a good idea?

Even if this include path likely causes no problem, is that what we want, is that the way it should be? I say no. The compiler should do exactly what you tell it to do, not perform any MS-style capers.

[tiwag]

hehe  :shock:

[klight]

Forgive my ignorance, but perhaps there is a different approach...

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.

[rickg22]

Hmmm interesting idea. It may work. Ok, let me jump into the bandwagon and suggest the addition of this flag in the project's build options.

[ ] Add Extra search paths like MS-VisualStudio (WARNING: NOT recommended for cross-platform projects since it's not ISO-C++ compliant)

This flag could be set for importing MSVC projects

[thomas]

Forgive my ignorance, but perhaps there is a different approach...

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.

That's not ignorance at all. That's the correct way

[mandrav]

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.

Well, I would normally agree with you but this is a case where it doesn't hurt. The reason is that what I added is "." (current dir) from the compiling-file's point of view. The current dir, unless overriden, is implicitely included in the search list. The only difference here is that because C::B uses the project's dir as the current dir, we "help" the compiler by adding the file's current dir in the list .

I hope it makes sense the way I wrote it 

[tiwag]

@thomas : you are right, IT IS A BUG !!!

after updating CB to rev 1813 i tried to rebuild any of my plugin's and earned a lot of undefined symbols errors

after reverting /trunk/src/plugins/compilergcc/cmdlinegenerator.cpp to rev 1810 it behaves ok again !

[killerbot]

I agree with Thomas on this. We should not add secretely extra paths, to get something to compile.

[troels]

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.

Problem is that the number of search paths tends to add up in non-trivial projects, yielding a compilation speed hit. And gcc is a terrible slow compiler already (it has advantages too naturally, but not speed).
Likewise Yiannis' fix, neat and straightforward as it is, is bound to yield a slight compilation speed hit too (adding one more search path). I'd personally vote for invoking gcc in the source module's directory (no added search path), but perhaps Rick's suggestion is most likely to make everybody happy.

The compiler should...not perform any MS-style capers.

What's wrong in catering for MS-users a bit? Lots of potential users there. An elitist gcc-is-god stance is not likely to benefit the project much.

The sentence you quoted from the website, does not mean that we 'll work for any crazy idea anyone might have. And for free.

Likewise I provided feedback for free. Qualified feedback even, I believe. One dev makes a move to bury this suggestion of mine, and for objecting to this I get called crazy. I'll be silent.

Logged out.

[sethjackson]

I agree with Thomas on this. We should not add secretely extra paths, to get something to compile.

Yup. I'll have to agree.

[Michael]

I agree with Thomas on this. We should not add secretely extra paths, to get something to compile.

Yes, I agree on this too.

Michael

[mandrav]

OK, I think enough have been said about the issue.
The commit log of r1820:

* Added compiler-independent option to explicitely add the currently compiling file's directory to the compiler's search dirs. This fixes once and for all the bug with revision 1813 and allows it to be configurable. Default is *not* to add this dir behind the scenes (i.e. the way it always was).

Although the first "fix" for this issue had a bug, it still needed to be applied. You all failed to see that there really is an issue here and troels was right to bring this up.
And Thomas, Rick, et al, it's not a MSVC-specific hack. If you think about it, it would have occurred with the test project troels attached even if it was using GNU autotools. Autotools do change the working dir to the file's dir also, like MSVC. This would fail there too, so to sum it up, this really was a C::B issue which got fixed the easiest way: let the user decide how to handle this.

I 'm not blaiming anyone here, I 'm just saying you failed to see the issue. After all, I was the one that told Thomas to close this bug report as invalid when he asked me what to do...