Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Two small problems - Compiler switches and dependecies
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:
--- Quote from: MortenMacFly on July 25, 2006, 10:48:19 pm ---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?
--- End quote ---
Yes, of course ;)
--- Quote from: MortenMacFly on July 25, 2006, 10:48:19 pm ---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.
--- End quote ---
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:
--- 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.
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: :P
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. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version