-an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)

[Tomas Hajny]

On 9 Feb 12, at 23:09, Sven Barth wrote:
> On 09.02.2012 22:14, Mark Morgan Lloyd wrote:
> > Sven Barth wrote:
> >> On 09.02.2012 18:59, Mark Morgan Lloyd wrote:
> >>> Tomas Hajny wrote:
> >>>
> >>>> Yes, this is what I suggested to do above; for -an, not in general,
> >>>> because I don't know of such dependencies myself (I wasn't aware of it
> >>>> for
> >>>> -an either).
> >>>>
> >>>>
> >>>>> (b) having a line in the banner showing what non-default options were
> >>>>> used during build?
> >>>>>
> >>>>> Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
> >>>>> Copyright (c) 1993-2011 by Florian Klaempfl and others
> >>>>> Built with EXTDEBUG, fvm32.
> >>>>
> >>>> I'm afraid that this is "a bit" more difficult _if_ we want a general
> >>>> solution. Addressing individual options explicitly is possible
> >>>> (probably
> >>>> line by line rather than as a list though). Obviously, this wouldn't
> >>>> be a
> >>>> general solution. However, I'm not aware of any compiler macro
> >>>> allowing to
> >>>> list all conditional defines (that would be still the easier part,
> >>>> because
> >>>> these are obviously known within the compiler so adding a new macro
> >>>> should
> >>>> be possible, but it may be a long list), and even less a macro
> >>>> allowing to
> >>>> list just compiler defines added explicitly on the command line (rather
> >>>> than defined internally for a particular target, implied from some
> >>>> other
> >>>> command line options or defined within the respective source
> >>>> file)... I'd
> >>>> wait for opinion of other core team members whether we should add
> >>>> support
> >>>> for explicit "Built with EXTDEBUG" or do something else (but I'm
> >>>> certainly
> >>>> not the one who'd add a macro necessary for the general solution).
> >>>
> >>> I suppose another possibility would be to have something in the makefile
> >>> that captured the shell/environment variables, in the same way that the
> >>> Lazarus build captures the revision number if available. But that's not
> >>> in the same league as putting useful info in the banner.
> >>>
> >>> I think a good starting point would be a line that showed any
> >>> definitions that were known to have an effect on the interpretation of
> >>> the options, e.g. EXTDEBUG and- in particular- the exact target CPU when
> >>> this wasn't the default.
> >>>
> >>
> >> What about this (using an example application instead of the compiler):
> >>
> >> === source begin ===
> >>
> >> program envtest;
> >>
> >> const
> >> crossopt = {$include %CROSSOPT%};
> >> opt = {$include %OPT%};
> >>
> >> begin
> >> Writeln('CROSSOPT: ', crossopt);
> >> Writeln('OPT: ', opt);
> >> end.
> >>
> >> === source end ===
> >>
> >> The Makefile used below just calls "fpc envtest.pp" for "all".
> >>
> >> === shell begin ===
> >>
> >> [sven at artemis oneshots]% make all OPT="-dEXTDEBUG" CROSSOPT="-CfSSE2"
> >> fpc envtest.pp
> >> Free Pascal Compiler version 2.6.0 [2011/12/23] for i386
> >> Copyright (c) 1993-2011 by Florian Klaempfl and others
> >> Target OS: Linux for i386
> >> Compiling envtest.pp
> >> Linking envtest
> >> /usr/bin/ld: warning: link.res contains output sections; did you
> >> forget -T?
> >> 10 lines compiled, 0.5 sec
> >> [sven at artemis oneshots]% ./envtest
> >> CROSSOPT: -CfSSE2
> >> OPT: -dEXTDEBUG
> >>
> >> === shell end ===
> >>
> >> For the explanation: make moves all variables into the environment
> >> which is inherited by the processes that are called by it. FPC can
> >> include the values of a environment variable at compile time (it will
> >> be '' if not set, though a warning will occur which needs to be
> >> disabled with $warn) and thus at least the values of OPT and CROSSOPT
> >> could be printed by the compiler (which should normally be
> >> sufficient...).
> >
> > One thing I'd caution about the environment is that Debian- and probably
> > others- predefines a significant number of shell functions, which shows
> > up in the output of the set command.
> >
> 
> If OPT or CROSSOPT is set in the environment already you might have 
> problems with compiling FPC at all (because it might contain 
> incompatible options) no matter whether we use it for output or not...

To let Mark (and Sven) know - I tried to add support for this to the 
compiler but I couldn't make it to work for OPT. The approach is OK 
in general (apart from the limitation that the compiler may also be 
compiled without Makefiles and potential use of whatever options 
wouldn't be visible in that case, but that scenario is probably not 
important). However, our Makefiles process these variables in very 
complex way and the result is that OPT is always empty during the 
compiler compilation (probably due to line 360 in compiler/Makefile). 
I thought that LOCALOPT might be used instead (see line 355) but that 
didn't work either. See the attachment (it's the stage when I wanted 
to try printing LOCALOPT too). Even if I use the original sample 
program from Sven and rename it to pp.pas and replace the compiler 
source file with it (and fix the warnings which are treated as errors 
due to -Sew added by the Makefile ;-) ), I only get CROSSOPT printed 
and OPT showed as empty.

So I ended up by only adding the note to the help page regarding -an 
dependency on -dEXTDEBUG...

Tomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: compopts.zip
Type: application/zip
Size: 693 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20120229/4a945a33/attachment.zip>