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

[Sven Barth]

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...

Regards,
Sven