Two small problems - Compiler switches and dependecies

[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]

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.

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.

[MortenMacFly]

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

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]

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.

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 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]

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. [...]

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]

   -g well does not exist -> drop it (easy to check)

But there are switches having the same meaning for another compiler, certainly (not offending, but just to keep that in mind).

- The best we could do, leave all those defines, include paths untouched [...]
- and list the 'removed' ones to the user.

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

- check the options to see if they exist in the new compiler and keep those (bad luck if they change meaning)

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.

[MortenMacFly]

Two remarks as a side-note (slightly off-topic):
1.) I just tried: The -g switch is available under "Other compiler options" if you have changed the compiler. So you actually can remove it after the switch.
Maybe there also the "non-convertible" options could be printed for our approach and focussed to this box afterwards. Thus the changes would require zero GUI change... ;-)
2.) I would be interested why you (obviously) have setup different projects for different compilers and not different targets for the different compilers within a single project. Is it for dependency stuff? (I'm just curious because I might missing something since both of you seem to prefer this kind of setup.) You can PM me if you like to avoid spoiling this thread.

[Der Meister]

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?

Yes, of course

2.) I would be interested why you (obviously) have setup different projects for different compilers and not different targets for the different compilers within a single project. Is it for dependency stuff? (I'm just curious because I might missing something since both of you seem to prefer this kind of setup.) You can PM me if you like to avoid spoiling this thread.

Well, I found this by accident. I installed a nightly build here on windows and only have two Microsoft compilers installed. But GCC (or MinGW) was selected as default with -g as option. I changed it to MS Visual C++ 2005 (which was correctly auto-detected and worked just fine). Then I noticed that it complains about the unknown option -g.

[mdelfede]

I think all problems with compiler switches, rebuilds when needed, etc. could be fully resolved only implementing a compiler framework with configuration files in xml.
There you could put the equivalence of switches (if any) between compilers, the 'need rebuild' flag and so on.
The best would be of course the automatic conversion of switches when changing compilers, with maybe an alert for switches that can't be converted.
This means of course quite complex compiler configuration files.

Another possible (temporary) solution would be to store the switches for the selected compiler and to blank them when changing it (or restoring the previous ones if any). At least the switches would not be lost switching forth and back from compilers... but with the big caveat that changing a switch in one compiler setting would not update it on others.

Ciao

Max

[MortenMacFly]

fully resolved only implementing a compiler framework with configuration files in xml.

I don't think so. There is no "minimal-compatible-same-meaning-accross-all-compilers-swichtes-set". In fact you will have compilers that share not even a single switch in common - trust me, I know. And there are switches that have only "nearly" the same meaning. For example: The warning levels for several compilers are from 1 to 3 and for others from 1 to 5. So how do you convert e.g. warning level 2 of the second one? And is it appropriate to say that both "warning level 1" are defined to have the same meaning? I don't think so.

And again, as I had said in another thread already: You can never-ever expect that this can be done fully automatic without errors. In addition to have a "smart" conversion someone would have to know and maintain all (!) compilers supported by C::B. Who is the one that has e.g. enough money to buy them all? My C::B incorporates 16 compilers already and there are more to come onces the compiler framework re-design has finished. I can only warn to expect that all such "fancy clever automatic stuff" is possible, because it simply won't. But of course you can prove me wrong with a patch.

[takeshimiya]

Ok, I see two solutions to this, which can be combined:

1) Compilers being a child of target and project
Suppose you have a target with a MinGW's -g option.
Now you select MSVC on the same target: all the options are cleared for the MSVC compiler (since they are invalid in MSVC).
And now, you will want to "port" some of the switches to MSVC, then you go back and forth between MSVC and GCC.
This haves two benefits: no settings is lost at all, never. No setting is invalid at any moment.

And a side benefit: We can put in the C::B toolbar, a "Current compiler" combobox, so you can select the current compiler at a project level (which would come very handy). Thus, without requiring you to make different targets when using different compilers (but you can still make different targets if you wish).

The dependency tree would be then:
Workspace
    Projects
       Targets
           Compilers

Instead of the current
Workspace
    Projects
        Targets[compiler]

2) Common options between compilers
This is the easy part because it has been said that it will be done:
In the new xml compiler framework, sets of common options between compilers will exist.

Example:
Debugging on
    MinGW: -g
    MSVC: /Zi
    DMars: -v
Optimize for size
    MinGW: -Os -s
    MSVC: /Os /O1
    DMars: -O1
and so on.

Note: this is not an entire mapping of settings from one compiler to another.

With this two solutions combined, most bold problems are solved in this topic.

In addition, a 3rd. solution can be added:
3) ToDo list of settings left to translate
A little wizard settings exporter from one compiler to another (fine-grained):
A floating window would appear, with the settings of the compiler 1 you need to translate at hand to the compiler 2.
And once you have found how do you want to translate eg. MSVC's /W1 to MinGW, that item will be removed from the list.
So this would be something like a little ToDo list of settings left to translate.