Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Two small problems - Compiler switches and dependecies

(1/6) > >>

Der Meister:
Using revision 2779 (Nightly Build from 24.07.2006) I noticed two minor problems.

First one:
Have a project and select GCC or MingWG as compiler. Activate the compiler switch for creating debug information (-g). Now select another compiler for this project (for example one from Microsoft) that does not support -g as command line switch. Now compile the project with this compiler. Notice that the compiler will complain about an unknown option '-g'. That means: It gets the old parameters for the previous selected compiler, too (or at least a part of them). This should not happen because it might cause problems if the parameter is a correct switch for the second compiler but causes totally different behaviour when passed to the first one.

Second one:
Have a workspace with two projects in it. For example project one with only one file named 'main1.cpp' and project two with only one file named 'main2.cpp'. Build both projects. Then add a dependency: Project one now should depend on main2.cpp. Change something in main2.cpp, save the file and hit "Build" for project one. The project is rebuild because main2.cpp was changed. This works as expected. Now change again something in main2.cpp but this time do not save it. Hit "Build" for project one and Code::Blocks will report that there is nothing to do. This is not true because main2.cpp was changed. As user I would expect that Code::Blocks saves main2.cpp (as it does for unsaved files in project one) and then rebuilds project one.

killerbot:
could you file 2 bug reports for this please. Nice feedback.
The first one you can assign to me, I am working on those compiler options, bunch of issues in that corner.

Der Meister:
Done except that I was not able to assign it to you. It seems that only members of the project on berlios can do that :)

MortenMacFly:

--- Quote from: Der Meister on July 25, 2006, 09:20:03 pm ---First one:
Have a project and select GCC or MingWG as compiler. Activate the compiler switch for creating debug information (-g). Now select another compiler for this project (for example one from Microsoft) that does not support -g as command line switch.

--- End quote ---
I really don't agree on that one. If all compiler switches are lost when I switch the compiler how am I supposed to "port" the compiler switches to the new compiler?
I think C::B just acts right. It keeps the compiler switches as they are not trying to be "damn smart". If I as developer switch a compiler I have to take care to convert the build options (including compiler, linker, libs, defines...) etc by myself. That's what I would expect. To do so I need to know the old ones and then it's a step-by-step conversion.
Changing the compiler for a project is a non-trivial change. No one can expect an IDE to be smart enough to handle all the possible switches and settings correctly. Especially since C::B supports that many compilers (including version of compilers). Keep it simple! A dev that is gooing to convert a project using another compiler usually *knows* that he has to "port" switches, too and how. That's my opinion.

With regards, Morten.

killerbot:
I am working a lot with projects that build sources for a different set of compilers; But mostly I copy/paste yje project files (way faster ;-) ).
I do agree with Der_Meister (sorry Morton ;-) ), that it might be best if you change the compiler you should start clean, the same argument holds an experienced developer will know which ones to (re)add again. Starting clean seems less error phrone to me then starting from a mix.

[EDIT] : to make my point a bit stronger ;-) : we already had several topics/questions from people stating that they build something and certain settings were not intended for the compiler they used, so experience seems to show people suffer from it.

Navigation

[0] Message Index

[#] Next page