[fpc-devel] New -Xg option in the last 9778 revision

[Tomas Hajny]

On 18 Jan 08, at 22:29, Michael Van Canneyt wrote:
> On Fri, 18 Jan 2008, Flávio Etrusco wrote:
> 
> > > > > That is partly true. The problem is that setting -Xs doesn't help if there is also -g in the
> > > > > command line. So people think that the compiler strips the executable, but in fact the binary is
> > > > > unstripped.
> > > > >
> > > >
> > > > But why doesn't FPC spit a warning when these (seemingly conflicting)
> > > > options are used?
> > >
> > > It silently switches off -Xs when debug info is selected.
> > >
> > > Michael.
> > 
> > Don't you think it should display a warning?
> 
> I can imagine some people do :-)

This requirement would bring additional complexity to processing of 
compiler options. As of now, there are at least four ways to set 
compiler behaviour:

1) Internal compiler defaults.
2) Configuration files (note that these may be fairly complex with 
IFDEFs and include files)
3) Command-line options
4) Compiler directives within source files - e.g. {$MODE xxx} (not 
applicable to all kinds of command line options, of course)

It's quite common to have some default set at some of these levels 
and override this default on a different level, and you probably 
wouldn't want to emit warnings in this case. Moreover, more complex 
configuration files may intentionally include "conflicting" options 
(because of overriding) too - imagine a configuration file like this:

-Xs
#IFDEF DEBUG
 -gl
#ENDIF DEBUG

In this case, adding -dDEBUG on command line intentionally overrides 
the previous part of the configuration file - again, probably no 
reason to emit any warning.

Now, what all this means for FPC - as of now, we process the options 
in linear way. Internal compiler defaults are during initialization 
of the compiler. Then we configuration files are searched and if 
found, read in linear way - if some option is found, it turns 
particular behaviour on or off. If the next option switches the 
behaviour back, FPC doesn't know it (and it doesn't care), because 
that request was already processed before. In order to change that, 
FPC would probably need to maintain two parallel structures for 
setting the behaviour - one temporary used while processing certain 
level of configuration as listed above, another where the results for 
the particular level would be copied after that level is completely 
processed (that one would need to include reference to the particular 
option turning the feature on in order to show proper warning message 
- some of the features may be turned on in different ways). Although 
this is certainly doable, it's certainly much more complex than the 
current implementation...

Tomas