Out of interest compiler settings...

[CarlYoung]

The current design for the tool settings seems a bit inflexible to me and I'm wondering what desire there is to change this? Is there a long-term development plan?

As I mentioned in the OW thread, some compiler options are only applicable to the C++ compiler so I would like to see them disabled for C source files. This would have to be

Other little things like ordering of arguments can be important. In Watcom, some arguments will reset other arguments. You may specify full debug information then enable an optimization switch. If the order is reversed, switching on debug disables the optimization.

What about grouping of settings to provide a "one of n" choice? Currently, you can enable multiple settings that conflict with each other such as target platform being specified mutiple times.

Is there already a drive to redesign some of the option handling or should I put this on a wish-list and come up with a proposal?

Carl

[mandrav]

Is there already a drive to redesign some of the option handling or should I put this on a wish-list and come up with a proposal?

There are plans to redesign the way compilers are defined but not before v1.0 is out (too big change for now).
But specifically for compiler options, in the way you put it (like options ordering), no there are no plans. So if you have any proposals/ideas, please share them

Yiannis.

[Profic]

I have proposal for USER look and feel, e.g. how it could be done, how it will be emplemented up to you

First of all, change checkboxes with comboboxed (err, list with one selection), all current checkboxes can be converted to comboxes with yes/no in them.
This step allow us to group conflicting options to one, e.g. debug symbols format, arch, optimization, etc...
Next, if one value of option disables effect of other options (like -Wall) just make them disabled to indicate them
More, some options possible only for particular language (for example -Wmain issue warning for c++ file), so they must be changeable in setting, but also somehow marked what language they apply to, just as not putting them anyhow to command line for particular compiler
All of this seems not hard to do, but allow more interactivity to compiler option. As a result newbies will better understand what they do.

Also it seems reasonable for setting somewhere to show switches that will be added for particular option value (for real geeks
And the most impossible feature - just allow users to modify options, so they can not only put them in Additional options, but define them and share definition

What do you think about this?

[mandrav]

All sound reasonable. Implementation is another thing though

And the most impossible feature - just allow users to modify options, so they can not only put them in Additional options, but define them and share definition

This is not impossible. As a matter of fact, I 've been thinking about implementing it the last few weeks. I mean, if the config importer was functional, it would already work like this. The only thing left would be a small dialog to add/edit options.
But I decided not to proceed with this, as I saw that the current system has some shortcomings which call for a better design...

Thanks for the input,
Yiannis.

[Profic]

Well, let's wait for implementation... Long wait

PS. However I can't wait for new current release, as one big thing annoying me currently is MDI interface
PSS. Sorry, can't help with anything, as currently working on project, which must be finished yesterday...