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

Two small problems - Compiler switches and dependecies

<< < (5/6) > >>

killerbot:

--- Quote from: thomas on July 26, 2006, 10:21:22 am ---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.

--- End quote ---

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:

--- Quote from: thomas on July 26, 2006, 10:21:22 am ---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.

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

mdelfede:

--- Quote from: thomas on July 26, 2006, 10:21:22 am ---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.


--- End quote ---

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:

--- Quote from: Der Meister on July 26, 2006, 11:21:15 am ---
--- Quote from: thomas on July 26, 2006, 10:21:22 am ---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.

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

--- End quote ---
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.


--- Quote ---Btw, a possible good solution would be like that :
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page