Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Two small problems - Compiler switches and dependecies
MortenMacFly:
--- Quote from: killerbot on July 25, 2006, 10:22:32 pm ---[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.
--- End quote ---
Ok, but I still disagree to delete all references to the old switches. Maybe a textbox or something still shows the old switches with a hint that they need to be converted. But I really want to have a reference that I know what to convert. Otherwise I could swear we are getting the same number of bug reports complaining that suddenly the project won't compile because of wrong (missing) compiler options.
BTW: I'm using different compilers, too having them in different targets. I'm usually copying the target and convert the specific compiler options then for this very target. So you see: There are several ways how things can be done and I really still believe that removing all options is not the best we can do.
With regards, Morten.
Der Meister:
--- Quote from: MortenMacFly on July 25, 2006, 10:12:22 pm ---
--- 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?
--- End quote ---
I didn't say they should be lost. In fact I would expect Code::Blocks to remember the options and use them again if I switch back to gcc.
But now it passes the parameters for gcc to MSVC if I select this compiler. And I have no chance to deactivate -g for MSVC - because this option does not exist. I would have to switch back to gcc, deactivate the option and then switch to MSVC again. This is not really nice. Anyway, with -g there is no real problem - MSVC just says it does not know this option. But what will happen if you use switch that is known by both compilers but acts totally different? You might get big problems but no one would tell you about them.
As killerbot said: It should be safer if you start with a clean option set if you change the compiler. Or even better: Get the options you selected last time for this compiler or a clean set if you use it the first time for this project (with respect to global settings, of course).
MortenMacFly:
--- Quote from: Der Meister on July 25, 2006, 10:34:20 pm ---I didn't say they should be lost. [...]
As killerbot said: It should be safer if you start with a clean option set if you change the compiler. [...]
--- End quote ---
So we are getting closer to a better solution I think. All I'm asking for is *not* to delete them but having them available (visible) as reference for converting. I agree that it would be good to have the copied project/target with clean options then. Can we stick with this and then think how to achive this?
BTW: How do you copy a project in C::B? or do you mean to open a copy of the project file, too? Or do you mean targets (they can be copied and that's what I'm doing)...?!
killerbot:
it is even more complex :
- compiler options
-g well does not exist -> drop it (easy to check)
-XYZ : does exist but totaly different meaning --> what to do, although it was also easy to check
- all those other options
- defines
- libraries
- includes/resources/library paths
- policies
It is so complex that trying to keep everything is gonna fail. We should certainly warn the user thet a compiler switch (normally) will make all settings illegal (and as Der meister show you are not even able to uncheck those options since they don't exist). The best we could do, leave all those defines, include paths untouched (for the majority of cases they are nearly compiler independent (example proving the opposite those new defines from M$ to get rid of their depracated and please use our so safe implementation of printf warnings)), check the options to see if they exist in the new compiler and keep those (bad luck if they change meaning) and list the 'removed' ones to the user.
MortenMacFly:
--- Quote from: killerbot on July 25, 2006, 10:41:50 pm --- -g well does not exist -> drop it (easy to check)
--- End quote ---
But there are switches having the same meaning for another compiler, certainly (not offending, but just to keep that in mind).
--- Quote from: killerbot on July 25, 2006, 10:41:50 pm ---- The best we could do, leave all those defines, include paths untouched [...]
- and list the 'removed' ones to the user.
--- End quote ---
Agreed. Sounds good to me. But there are many SDK's (e.g. Irrlicht) that provide libs for several compilers in several lib folders as an example. Thus compilation would be broken. So most important is to warn the user (100 times ;-)) about that the conversion may have failed and he *has* to verify this (as you said, killerbot).
--- Quote from: killerbot on July 25, 2006, 10:41:50 pm ---- check the options to see if they exist in the new compiler and keep those (bad luck if they change meaning)
--- End quote ---
As you said: This can lead to new issues. But having the strong warning (in red, blinking, making sound... ;-)) it should be acceptable.
Alltogether: I would like to ask Yiannis and Thomas and all the other core devs about their thoughts. So I really think implementing this should wait until they are back and have read this thread. Can we agree on that? (BTW: I'm off the next days, too until sunday).
With regards, Morten.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version