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

Two small problems - Compiler switches and dependecies

<< < (4/6) > >>

mdelfede:

--- Quote from: MortenMacFly on July 25, 2006, 11:38:01 pm ---
--- Quote from: mdelfede on July 25, 2006, 11:10:33 pm ---fully resolved only implementing a compiler framework with configuration files in xml.

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

--- End quote ---

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:

--- Quote from: mdelfede on July 26, 2006, 02:30:31 am ---
--- Quote from: MortenMacFly on July 25, 2006, 11:38:01 pm ---
--- Quote from: mdelfede on July 25, 2006, 11:10:33 pm ---fully resolved only implementing a compiler framework with configuration files in xml.

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

--- End quote ---

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


--- End quote ---

lol, that's exactly what I wrote in the previous post: http://forums.codeblocks.org/index.php?topic=3669.msg28922#msg28922 :P
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:

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

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page