-an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Thu Feb 9 22:14:08 CET 2012
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel
mailing list