Am 29.02.2012 00:31, schrieb 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@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@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...
Well... thanks for trying anyways ;)
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
