Adriaan van Os wrote:

The graphical user interface of an IDE option panel for the GNU Pascal compiler, could have checkboxes for options iike "short-circuit", "extended-syntax" and many other.

Now, if the user e.g. checks the "short-circuit" checkbox and unchecks the "extended-syntax" checkbox, the IDE plug-in could choose (1) to pass no command line arguments to GPC for these options, because both are set to their default (2) to pass command line arguments for both options, whatever their default.

The disadvantage of (1) is that it breaks if the default changes or if the documentation is wrong,

You could try to get the information from gpc-options.h which is the code that GPC uses. However, you'll probably have to write C code, or convert the file (simple text substitution) in order to use it in Pascal (or whatever form you need). But if you want to allow for different GPC versions, this might be problematic. (Well, it will be problematic anyway, if there are new options that older versions don't understand ...)

of (2) that it cumulates into a very long list of arguments. Any advice on what is the lesser evil ?

Unless you're on a system with strict command-line length limits (but even on Dos, this shouldn't be a problem if the IDE runs under DJGPP as well, because DJGPP programs can pass longer command-lines between each other), (2) might only be a "cosmetic" disadvantage ...

You still have to be careful of option implications (again, see gpc-options.h for the detailed list). Mostly, that's the dialect options (so these should be the first), but there are a few more.

Things become more difficult if the default for an option depends on the Pascal dialect, as with "ignore-packed" and other options. Here, a three-state user interface element "default, yes, no" may be the alternative.

This might be the best solution. For the dialect you'll have a multi-state option, anyway, where `--gnu-pascal' is the same as "default" (since it's first on the command-line, i.e. it can't undo a previous other dialect option), so it would seem systematic.

(Side note: I generally suggest to put such options, especially those that are required to compile some code at all, into the source (unlike those that depend on the environment, cf. my reply to Peter yesterday) ...)

Frank

Peter N Lewis wrote:

At 11:27 PM +0200 15/7/03, Adriaan van Os wrote:

...

Now, if the user e.g. checks the "short-circuit" checkbox and unchecks the "extended-syntax" checkbox, the IDE plug-in could choose (1) to pass no command line arguments to GPC for these options, because both are set to their default (2) to pass command line arguments for both options, whatever their default.

The disadvantage of (1) is that it breaks if the default changes or if the documentation is wrong, of (2) that it cumulates into a very long list of arguments. Any advice on what is the lesser evil ?

You could place them in a prefix file, but then that might clash with a user prefix file - does GPC allow two prefix files?

I'm not sure exactly what you mean by "prefix file". If you mean include files -- there can be any number of them included from anywhere.

But it's no solution here since not all options can be put into the source (e.g., optimization options since many parts of the compiler assume they do not change during compilation).

Frank