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.

[mdelfede]

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.

No, you're right, a FULLY AUTOMATIC option conversion with no errors is impossible (or at least too difficult), but a partial
thing can be done. Even, I think that for most common options shouldn't too difficult.
In the example of warning level you could choose the nearest : if you have 2 in a 1-5 range, you could do it with 2 in 1-3 range, not perfect but better than leaving blank. That could be done for other options like optimization, for example.
More exotic options could be put in a textbox as reminder when switching from a compiler to a new one, so it would be easy for people that knows it to set the correct options; they shouldn't let 'as-is' as meaningless options in the new compiler.
Most important, I think options should be saved when switching to a new compiler and restored when switching back, not perfect too but spares lot of thinking and typing :-)

Ciao

Max

[Typz]

I could imagine a kind of "compiler conversion wizard", which presents two columns, for old and new compiler, and one line per option. On the left side, you see the old compiler option (with name if it known); on the right side you got a combo box which allows you to select a known option, or type in any option you want. That way, you see the complete list of options for the old compiler, and can easily match it to options for the new one.

If somehow C::B knows how to match some options, those can be set already, and the user can double check that in any case.

Moreover, the same idea can go with path, libraries & so on.... So we can have a full wizard, with first page for the options, 2nd page for the path, 3rd page for the libraries..... Obviously, if C::B can completely match the options/libraries... (because only basic options were used), the corresponding page in the wizard would not be displayed (or even the whole wizard, if everything could be converted).

[takeshimiya]

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.

No, you're right, a FULLY AUTOMATIC option conversion with no errors is impossible (or at least too difficult), but a partial
thing can be done. Even, I think that for most common options shouldn't too difficult.
In the example of warning level you could choose the nearest : if you have 2 in a 1-5 range, you could do it with 2 in 1-3 range, not perfect but better than leaving blank. That could be done for other options like optimization, for example.
More exotic options could be put in a textbox as reminder when switching from a compiler to a new one, so it would be easy for people that knows it to set the correct options; they shouldn't let 'as-is' as meaningless options in the new compiler.
Most important, I think options should be saved when switching to a new compiler and restored when switching back, not perfect too but spares lot of thinking and typing :-)

Ciao

Max

lol, that's exactly what I wrote in the previous post: http://forums.codeblocks.org/index.php?topic=3669.msg28922#msg28922
I don't see any caveats.

[thomas]

Issue 1
... is a long-known problem. It is annoying and, unluckily, not trivial to solve for now. The compiler-independent behaviours in the new compiler framework may ease this pain a little bit, but to completely solve the issue, we will probably have no other choice than to save compiler sets with projects, which would be quite a massive change once again (otherwise, you'll have no choice but to lose any kind of setting that is not a behaviour).
In the mean time, losing all settings when switching compilers is the only really safe and working solution that I can think of.


Issue 2
... is (in my opinion) correct behaviour, even though unintuitive.
Yes, I would expect main2.cpp to be saved too (because that's what you have in your mind here), but strictly, this would be incorrect, it is not what should happen.
That sounds like a contradiction, since what you think will happen is what should happen, normally.

However, if you build a project, then the files belonging to that project should be auto-saved, but not any other files. You might have 3 dozen other files open (maybe some system files that you modified in the editor?) and you certainly would not want all of these to be written to disk.

The problem in this case is that you have an idea in mind which is good and all, but the IDE has to guess (by divination or some other occult measure) that you want to do something that is normally not correct.

I wonder if it would be worthwile (and correct) to treat dependency sources as if they were part of the project for the sake of automatically saving them. While doing a wrong thing, this would probably do what people want in your case and would not cause havoc to all others. Or so I hope...

[kidmosey]

I wonder if it would be worthwile (and correct) to treat dependency sources as if they were part of the project for the sake of automatically saving them. While doing a wrong thing, this would probably do what people want in your case and would not cause havoc to all others. Or so I hope...

Could you just change autosave to save all projects defined/loaded in the current workspace?  Then, any of the other dozen files you are editing that are not a part of any of your projects will not be autosaved, but any files that any of your current projects depends on will be saved.

[killerbot]

Issue 1
In the mean time, losing all settings when switching compilers is the only really safe and working solution that I can think of.

I'll give that a try in in my fixing of the compiler settings issues.



Extra note :
If you switch compilers, it is best you do it at the beginning, say you want to create a program using the MS compiler, so there's little setttings to copy at that time. And otherwise I would advice people to use a new target, then you can always compare with the other target to see which settings should still be copied. Will also give it a try to show the settings, in a little dialog to the user, he's going to loose because of the compiler switch.

[Der Meister]

However, if you build a project, then the files belonging to that project should be auto-saved, but not any other files. You might have 3 dozen other files open (maybe some system files that you modified in the editor?) and you certainly would not want all of these to be written to disk.

But why should I edit them if I don't want to save them?

[mdelfede]

Issue 1
... is a long-known problem. It is annoying and, unluckily, not trivial to solve for now. The compiler-independent behaviours in the new compiler framework may ease this pain a little bit, but to completely solve the issue, we will probably have no other choice than to save compiler sets with projects, which would be quite a massive change once again (otherwise, you'll have no choice but to lose any kind of setting that is not a behaviour).
In the mean time, losing all settings when switching compilers is the only really safe and working solution that I can think of.

Yes, I think that save compiler(s) sets and settings with the project is a must.
Would be also nice as I posted before to have the compiler settings in a textbox as a reminder when switching to a new compiler, so they can be used as a guideline to set options in the new compiler.
As you said, dumb copy of switches between compilers make no sense, better leave them blank.

Btw, a possible good solution would be like that :

1) Create a file (text, xml...) with human readable compiler option descriptions. That file could be grow indefinitely adding compilers.
2) For each added compiler, add another file with 1 to 1 relation with the first one, matching the human readable string with real compiler setting.
3) If a compiler don't have a corresponding setting, leave it blank; this should issue a warning when switching compilers.
4) If a compiler have less options than in first file (for example, warning level), the correspondence with human readable file will have some repetitions (i.e. match warning level 1 to 1, 2 and 3 to 2, 4 and 5 to 3).

That would be a big initial work, but then the only each compiler mantainer should only add to corresponding file when human readable file grows, or make it grow if newer versions make more options available.
That should avoid the "one mantainer must know all beasts" problem.

Ciao

Max

[killerbot]

do note : the moment you plug in your own compilers (!!) , for example for embedded platforms, things might look totally different.

I think at first we should consider this very advanced, and advanced users know what they are doing and will be able to hand made  those things. If we take it too complex from the beginning we will never see the end of it.

[thomas]

However, if you build a project, then the files belonging to that project should be auto-saved, but not any other files. You might have 3 dozen other files open (maybe some system files that you modified in the editor?) and you certainly would not want all of these to be written to disk.

But why should I edit them if I don't want to save them?

When I need a larger bit of data or code from a file (more than 4-5 lines), I often open the file, edit its contents, and then copy / paste the modified contents to the destination file. More often than not, the source file would not compile after the edits, but that doesn't matter. After everything is done, I close the source file without saving.
Among other advantages, this does not pollute the undo/redo buffers of the destination file, no matter how many edits you made. You can always go back to the previously working version with one click. Auto-saving files regardless of project membership could cause a lot of havoc.

A similar problem arises when building a project. I am used to do as many things in parallel as possible. For example, when I am rather sure that my modifications will work out just fine, I continue editing files after hitting "build". That way, I can test the last saved version and make use of the "lost" time while the build is running.
The problem that is introduced by auto-save is that the IDE saves all modified files belonging to a target each time it switches targets (not only once at the beginning of the build). This is fine as long as you only ever edit files that belong to a target that has already been built.
However, in every other case, you will experience suddenly being taken away focus in the middle of a line and you will see a (unsurprising) compiler error two seconds later.

Thus, auto-save is not necessarily without problems. I still think that treating dependencies as belonging to the project only for the sake of saving them at build could be a good compromise.

Btw, a possible good solution would be like that :

That would be very unmanageable and quite heavyweight, too. Not only would you have to load the options for a dozen compilers even if you only ever use one, it would also make implementing a config dialog very clunky. Also, it would mean that new compiler contributions would have to modify these two fat files every time, which is not precisely nice, either.

[Der Meister]

Well, I guess you're right. Autosave can be problematic.

I still think that treating dependencies as belonging to the project only for the sake of saving them at build could be a good compromise.

I agree on that. Maybe we should have a switch to enable autosave on build (or do we already have one?). If activated it saves all files of the active project *and* all modified dependencies. If turned off it simply doesn't save anything.
I think it doesn't matter if you have the possible problems just in one project or in the whole workspace and probably in even more files, even system files (they should be read-only anyway, but this is not Code::Blocks's problem).
Autosave on build should be consistent, that means save all or nothing. That is what probably most users expect to happen.