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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
