Two small problems - Compiler switches and dependecies

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