> Re: [perl #37178] [PATCH] Quiet a few alignment warnings
> Thanks, (belatedly) applied.
Wow. I'd completely given up hope on that one.
So feeling inspired, I decided to try it out and see how things looked.
Alas, my first attempt failed:
$ rsync -av --delete svn.perl.org::parrot-HEAD parrot-current
failed to connect to svn.perl.org - Connection refused
I then tried fetching a snapshot. That seemed to work. There doesn't seem
to be an obvious way to get the svn revision number out of it, but
here's the timestamp:
$ cat .timestamp
1174288505
Mon Mar 19 07:15:05 2007 UTC
(time of this svn update)
This one falls over immediately during Configure. Even setting
verbose=2, I don't see why:
Parrot Version 0.4.9 Configure 2.0
Copyright (C) 2001-2007, The Perl Foundation.
[ . . . ]
Determining what C compiler and linker to use...
No compiler found (tried 'cc')
Yet 'cc' works perfectly fine, and has for years. I have changed
nothing in my build scripts.
Oh well, back to other work instead. Thanks for applying my patch,
though. Maybe someone else will pick up the task and try to document
and check parrot's alignment assumptions
--
Andy Dougherty doug...@lafayette.edu
> On Mon, 19 Mar 2007, chromatic wrote:
> > The heuristic for detecting a compiler is to invoke it with some sort of
> > help flag, where $cc contains the executable name of your compiler:
> >
> > $cc -h
> > $cc --help
> > $cc /?
> >
> > If there's another option to pass to your compiler that causes it to do
> > nothing except exit with a successful error code, we can put it in there.
> > (Checking $ENV{PATH} and trying to divine the proper extension is another
> > option, but I like that one a little less.)
> In my opinion, that way lies madness. Generating a list of options which
> all possible current and future compilers will accept is not only
> impossible, it's pointless. It's also aggravating that there's no way to
> override it or tell Configure "Yes, cc is my compiler even though it's not
> in your list."
>
> The only way to tell for sure if you have a working compiler is to try to
> compile and run something. After the user has been prompted for all the
> flags, simply try to compile and run a simple test program. If it works,
> fine. If it doesn't, then complain with an informative error message. (It
> may be appropriate to skip the 'run' step in a cross-compilation
> environment and hope that the user got the flags right if the compilation
> succeeds.)
What's the minimally-useful, cross-platform way to compile, link, and run:
int main() {
return 0;
}
I'm happy to make the change, but I spent the weekend struggling to figure out
how MSVC handles shared libraries, and I'm no longer sure that the easy
approach is that easy.
-- c
> On Monday 19 March 2007 08:19, Andy Dougherty wrote:
>
> > This one falls over immediately during Configure. Even setting
> > verbose=2, I don't see why:
> >
> > Parrot Version 0.4.9 Configure 2.0
> > Copyright (C) 2001-2007, The Perl Foundation.
> >
> > [ . . . ]
> >
> > Determining what C compiler and linker to use...
> > No compiler found (tried 'cc')
> >
> > Yet 'cc' works perfectly fine, and has for years. I have changed
> > nothing in my build scripts.
>
> The heuristic for detecting a compiler is to invoke it with some sort of help
> flag, where $cc contains the executable name of your compiler:
>
> $cc -h
> $cc --help
> $cc /?
>
> If there's another option to pass to your compiler that causes it to do
> nothing except exit with a successful error code, we can put it in there.
> (Checking $ENV{PATH} and trying to divine the proper extension is another
> option, but I like that one a little less.)
In my opinion, that way lies madness. Generating a list of options which
all possible current and future compilers will accept is not only
impossible, it's pointless. It's also aggravating that there's no way to
override it or tell Configure "Yes, cc is my compiler even though it's not
in your list."
The only way to tell for sure if you have a working compiler is to try to
compile and run something. After the user has been prompted for all the
flags, simply try to compile and run a simple test program. If it works,
fine. If it doesn't, then complain with an informative error message. (It
may be appropriate to skip the 'run' step in a cross-compilation
environment and hope that the user got the flags right if the compilation
succeeds.)
--
Andy Dougherty doug...@lafayette.edu
> This one falls over immediately during Configure. Even setting
> verbose=2, I don't see why:
>
> Parrot Version 0.4.9 Configure 2.0
> Copyright (C) 2001-2007, The Perl Foundation.
>
> [ . . . ]
>
> Determining what C compiler and linker to use...
> No compiler found (tried 'cc')
>
> Yet 'cc' works perfectly fine, and has for years. I have changed
> nothing in my build scripts.
The heuristic for detecting a compiler is to invoke it with some sort of help
flag, where $cc contains the executable name of your compiler:
$cc -h
$cc --help
$cc /?
If there's another option to pass to your compiler that causes it to do
nothing except exit with a successful error code, we can put it in there.
(Checking $ENV{PATH} and trying to divine the proper extension is another
option, but I like that one a little less.)
-- c
> I found the ticket that introduced this failing behavior, so I'm resending
> my message below with a fixed-up subject line to enter into RT. In brief,
> this patch incorrectly assumes that all compilers accept a '-h', '--help',
> or '/?' switch. Any compiler that doesn't is deemed 'not found', and
> there is no way to override it. Extending the list of options to try is
> not a sensible forward-looking portable strategy.
I realize this patch precludes cross-compilation at the moment, but does it
work better for you, Andy?
-- c
> In my opinion, that way lies madness. Generating a list of options which
> all possible current and future compilers will accept is not only
> impossible, it's pointless. It's also aggravating that there's no way to
> override it or tell Configure "Yes, cc is my compiler even though it's not
> in your list."
It's like Inline::C telling me that $Config{cc} doesn't appear to be a
compiler. Yes, you can't find "ccache cc" down my $PATH, but if you try
executing it, you'll find that it works just fine.
> The only way to tell for sure if you have a working compiler is to try to
> compile and run something. After the user has been prompted for all the
> flags, simply try to compile and run a simple test program. If it works,
> fine. If it doesn't, then complain with an informative error message. (It
> may be appropriate to skip the 'run' step in a cross-compilation
> environment and hope that the user got the flags right if the compilation
> succeeds.)
int main() {
return 0;
}
being a fairly good minimal example. I think that it's legal C++ too.
IIRC
main;
was found to be the shortest portable crash. :-)
Nicholas Clark
You can probably get by with whatever scheme is currently used to compile,
link, and run all the other tests in Configure, such as those to determine
sizeof(opcode_t) and the like. Perl 5's Configure uses the following
program:
#include <stdio.h>
int main() { printf("Ok\n"); return(0); }
The program includes output, and Configure tests for that output, because
we ran into cases where the program would compile, run, return a 'success'
exit value, but wouldn't actually print anything. The underlying problem
turned out to be a bug in SFIO's "iffe" configuration script (dealing with
_exit vs. exit, and the flushing of output buffers). So our "sanity" test
was expanded to include testing whether or not the program actually
printed what it was supposed to print.
--
Andy Dougherty doug...@lafayette.edu
Alas, no. Here's what I get (again with --verbose=2). I don't know why
it's reporting that the compiler is failling, and I don't know how to
coax Configure to give me any more information (short of sprinking
printf()s throughout).
I can definitely compile that test program with the indicated flags. I
don't have time to look at this further, however.
Determining what C compiler and linker to use...
Setting Configuration Data:
(
cc => 'cc',
);
Setting Configuration Data:
(
link => 'cc',
);
Setting Configuration Data:
(
ld => 'cc',
);
Setting Configuration Data:
(
ccflags => '-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
);
Setting Configuration Data:
(
linkflags => ' -L/usr/local/lib -R/usr/local/lib ',
);
Setting Configuration Data:
(
ldflags => ' -L/usr/local/lib -R/usr/local/lib ',
);
Setting Configuration Data:
(
libs => '-lsocket -lnsl -ldl -lm',
);
Setting Configuration Data:
(
cxx => 'c++',
);
Setting Configuration Data:
(
cc_debug => '',
link_debug => '',
ld_debug => '',
);
Setting Configuration Data:
(
ccwarn => '',
);
cc -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -c test.c
Compilation failed with 'cc'
--
Andy Dougherty doug...@lafayette.edu
Backed out until we find another solution to the problem.
Paul
> On Mon, 19 Mar 2007, chromatic wrote:
> > I realize this patch precludes cross-compilation at the moment, but does
> > it work better for you, Andy?
>
> Alas, no. Here's what I get (again with --verbose=2). I don't know why
> it's reporting that the compiler is failling, and I don't know how to
> coax Configure to give me any more information (short of sprinking
> printf()s throughout).
>
> I can definitely compile that test program with the indicated flags. I
> don't have time to look at this further, however.
Alright, I'll work on a better patch. We've pulled the previous one from the
upcoming release.
-- c
Ok. I've figured out what was going wrong:
+ unless ( eval { cc_build(); 1 } ) {
+ warn "Compilation failed with '$cc'\n";
+ exit 1;
+ }
This has two problems. First, it ignores the return value of cc_build().
That's understandable at the moment since cc_build doesn't seem to have a
documented return value. It should, of course.
The second problem is that this construct doesn't check for other errors
in the eval. Putting in C< warn $@ if $@;> reveals the problem:
Determining what C compiler and linker to use...Unknown open() mode '>&'
at lib/Parrot/Configure/Step.pm line 437.
Configure/Step.pm is apparently using a 3-arg open construct not
understood by my perl-5.6.2 version. But according to README:
You'll also need Perl 5.6.1 or above to run various configure and
build scripts.
The README is also consistent with this line in Configure.pl:
use 5.006_001;
So all that needs to be straightened out somehow, either by changing the
3-arg opens or by upping the perl version requirement.
Moving on:
+ unless ( eval { cc_run(); 1 } ) {
+ warn $@ if $@;
+ exit 1;
+ }
This also has the same ignoring-error return problem, but it's more
serious. If the program runs but fails (e.g. segfaults, or returns a
non-zero status) this bit of code happily continues on. I think it
probably shouldn't under such circumstances.
Of course, even after fixing those things, it still doesn't even come
close to working. More about that tomorrow as I try to sort out all the
other problems. Sigh.
--
Andy Dougherty doug...@lafayette.edu
Applied the patch with some modifications so that it runs correctly on
Windows in r21212. Tested on Linux x86, Windows and Cygwin.
Paul
I've managed to test this on Solaris and it works if one doesn't specify
a bogus compiler. However, if one does specify a bogus compiler for
instance by using the configure line:
perl Configure.pl --cc=moo
then for some reason the configuration with solaris continues, even
though it should barf. The problem exists around line 39 in
config/init/hints/solaris.pm. If one tries C<exit 1;> if the
C<run_command> call doesn't work, then configure just happily continues
configuring. How does one get configure to stop completely at this
point??? Using plain C<exit 1;> on Linux, Windows and Cygwin worked fine.
Paul
But did you actually address any of my objections? For example, do you
now pay attention to exit codes? Do cc_build and cc_run now have exit
codes?
--
Andy Dougherty doug...@lafayette.edu
The short answer here is: no. However attention to exit codes, and
exit codes from cc_build and cc_run are separate issues, aren't they?
A better thing to find out here is if parrot builds for you on your
platform. Does the current revision work for you? Then we can close
this ticket, and I'll open new tickets concerning exit codes from
cc_build and cc_run etc.
Paul
Actually, I thought I might as well implement exit codes from
C<cc_build> and see if i could improve C<cc_run>. See r21257 for
details. C<cc_run> already returns the slurped text from the relevant
calls within itself, so returning an error code might not be a good
thing (maybe the sub needs to be reimplemented). C<cc_build> now
returns an exit code.
In my earlier commit (getting Configure.pl to die more gracefully when
the compiler doesn't work) explicit C<exit 1;> statements are used so
that exiting is forced and exit codes from C<_run_command> are observed.
Does that help answer your objections?
Paul
I'm afraid I can't test it today (the system is unavailable) but I can
tell by just looking that even if cc_build fails, this will ignore the
failure and just keep churning along, so you won't get the "graceful 'no
compiler' message".
I guess I don't see the point of opening a new ticket to rehash the issues
of the old, and I don't see the point of closing this ticket until it
actually addresses the issues raised. (If cc_build and cc_run do get
meaningful exit codes, inter::progs needs to be revisited anyway to
actually use those codes.) But I also don't really care enough to argue
about it either. Do whatever you think appropriate.
--
Andy Dougherty doug...@lafayette.edu
The weird thing is that there *is* a graceful 'no compiler' message.
If cc_build fails then inter::progs exits with an appropriate error
message, and configuration stops at this point. I've tested this on
Linux, Windows and Cygwin. The only place this doesn't work is on
Solaris (for some reason C<exit 1;> just doesn't seem to want to exit
on this platform). Also, the problem on Solaris turns up in
hints::solaris, and I can't see what is being done specially there
such that things don't barf when we ask them to...
> I guess I don't see the point of opening a new ticket to rehash the issues
> of the old, and I don't see the point of closing this ticket until it
> actually addresses the issues raised.
Agreed. I'd like to get this issue solved as it is likely to help
other configuration steps which should also stop after an error has
occurred.
> (If cc_build and cc_run do get
> meaningful exit codes, inter::progs needs to be revisited anyway to
> actually use those codes.) But I also don't really care enough to argue
> about it either. Do whatever you think appropriate.
I apologise if this discussion is tiring. I'm not trying to make this hard...
Paul
> The weird thing is that there *is* a graceful 'no compiler' message.
> If cc_build fails then inter::progs exits with an appropriate error
> message, and configuration stops at this point.
That depends on the nature of the failure in cc_build. In the example in
the ticket, I was running cc_build with perl-5.6.2, but cc_build used a
form of 3-arg open available only in 5.8.x. Checking $@ would have
turned up that error.
Stepping back a moment, the following construct is just odd:
unless ( eval { cc_run(); 1 } )
What's the purpose of the '1' there? cc_run() should be given a
meaningful return value, and then that return value should be checked.
Also, any time you run an eval, it makes sense to check whether the eval
generated any errors. The cc_run() call checks $@, but the cc_build call
does not.
Here's something like what I have in mind. Don't apply this now -- it
won't work because it incorrectly relies on the return values of cc_build
and cc_run. Those values aren't even currently documented. There's a
decision to be made there -- shall they return '0 means OK' (reflecting
that (on Unix, at least) they are implemented in terms of system()) or
shall they return 'non-zero means OK'? The latter would allow them to be
used "naturally" with tests like: if (cc_run()) { print "Ok\n";}.
diff -r -u parrot-current/config/inter/progs.pm parrot-andy/config/inter/progs.pm
--- parrot-current/config/inter/progs.pm 2007-09-12 11:15:13.000000000 -0400
+++ parrot-andy/config/inter/progs.pm 2007-09-13 13:47:13.000000000 -0400
@@ -141,13 +141,19 @@
END_C
close $out_fh;
- unless ( eval { cc_build(); 1 } ) {
+ unless ( eval { cc_build() } ) {
+ warn $@ if $@;
+ # XXX Should be more verbose here -- write out the actual
+ # test program and command line that failed so that the user
+ # can easily reproduce and fix the problem.
warn "Compilation failed with '$cc'\n";
exit 1;
}
- unless ( eval { cc_run(); 1 } ) {
+ unless ( eval { cc_run() } ) {
warn $@ if $@;
+ # XXX Should be more verbose here -- See above.
+ warn "Running the test program failed with '$cc'\n";
exit 1;
}
}
> The only place this doesn't work is on
> Solaris (for some reason C<exit 1;> just doesn't seem to want to exit
> on this platform).
I'm afraid I don't know what you mean here. exit seems to work just fine.
I think you must be referring to some different problem.
--
Andy Dougherty doug...@lafayette.edu
> (If cc_build and cc_run do get
> meaningful exit codes, inter::progs needs to be revisited anyway to
> actually use those codes.)
If you do revisit config/inter/progs.pm, please bear in mind that I have
written some unit tests for that package:
[parrot] 500 $ ls t/configure/*progs* | cat
t/configure/107-inter_progs.01.t
t/configure/107-inter_progs.02.t
t/configure/107-inter_progs.03.t
t/configure/107-inter_progs.04.t
The extent to which these tests cover the code in the package can be
seen here:
http://thenceforward.net/parrot/coverage/configure-build/config-inter-progs-pm.html
So if you start refactoring, please make that a test-driven process so
that we keep the code coverage high. I'll be happy to point out any
pitfalls.
Thank you very much.
kid51
> Andy Dougherty wrote:
>
> > (If cc_build and cc_run do get meaningful exit codes, inter::progs needs to
> > be revisited anyway to actually use those codes.)
>
> If you do revisit config/inter/progs.pm, please bear in mind that I have
> written some unit tests for that package:
>
> [parrot] 500 $ ls t/configure/*progs* | cat
> t/configure/107-inter_progs.01.t
> t/configure/107-inter_progs.02.t
> t/configure/107-inter_progs.03.t
> t/configure/107-inter_progs.04.t
To be blunt, I am more interested at the moment in whether it's trying
to do something sensible than whether or not its actual current behavior
is being tested. Testing the existing behavior assumes that the existing
behavior is what the program should actually be doing.
Trivial example: Configure.pl currently supports many incompatible ways
to say "no" (excerpts from Configure.pl --help)
--nomanicheck Don't check the MANIFEST
--cgoto=0 Don't build cgoto core - recommended when short of mem
--without-gdbm Build parrot without GDBM support
--icu-config=none Can be used to disable the autodetection feature.
It will also be disabled if you specify any other
of the following ICU options.
Rather than testing that each one is handled correctly, it would make
more sense to design and implement a single way to say "no". Then you
can test the daylights out of that.
Sorry if this sounds too grumpy. Having a testing procedure, framework,
and culture is indeed useful, and your efforts there are appreciated.
But having a good design would also be useful.
--
Andy Dougherty doug...@lafayette.edu
I have agreed (in another thread), that these should be unified. So,
it's more a matter of TUITs than anything else.
> But having a good design would also be useful.
A good place to start is with a PDD-like summary of how it currently
works, if anyone is looking for a Perl 5-ish task.
Allison
>
> I have agreed (in another thread), that these should be unified. So,
> it's more a matter of TUITs than anything else.
>
> > But having a good design would also be useful.
>
> A good place to start is with a PDD-like summary of how it currently
> works, if anyone is looking for a Perl 5-ish task.
>
Somewhat apropos of this:
I've been discussing with Alan Rocker a research project in which we
would develop a table or spreadsheet that maps all the Configure.pl
command-line options to the configuration steps in which they are, can
be, cannot be, or should not be used. We're doing this as part of
preliminary planning for development of a file-based approach to
configuration (http://rt.perl.org/rt3/Ticket/Display.html?id=44315).
But once we have this we may be in a better position to discuss reforms
to the command-line options approach to configuration.
kid51
1. Should the Parrot configuration process come to a halt if any one
configuration step fails?
Right now, Parrot::Configure::runsteps() works as a harness: If one
step fails, it goes on to the next step.
2. Even if the failure of a configuration step typically does not stop
configuration dead in its tracks, are there some configuration steps
which are more important than others (e.g., inter::progs, with respect
to its test for the presence of a C-compiler) which ought to stop
configuration cold if they fail?
3. Let's assume that we grant inter::progs more importance than other
configuration steps. How should the absence of a working C-compiler be
detected and reported?
4. There are several Parrot::Configure::Step methods such as cc_gen(),
cc_build() and cc_run(). Since these methods are essentially wrappers
around system calls to C programs, how should failures in those
underlying C programs be reported and passed through the configuration
process? (Error codes? Messages?)
5. The Configure.pl command-line options do not have a consistent
design. How should they be changed -- or should they be? (Allison has
noted that this has already been discussed in a separate thread. That
thread is http://rt.perl.org/rt3/Ticket/Display.html?id=42412, open
since Apr 10, and that's where further discussion of this issue should
take place.)
Items 1 and 2 above imply an approach to configuration considerably
different from the one we now follow -- differences which, I suspect,
would entail the revision of a Parrot Design Document. If someone
thinks we should have that discussion, that someone should open up a
separate ticket to track that discussion.
Let's skip over item 3 for a moment. Since the Parrot::Configure::Step
methods mentioned in item 4 are used in many of the configuration steps,
improving them would have wide benefits. I myself am not sure exactly
how they should be improved, but I would recommend opening up a separate
RT ticket for each of those methods as needed.
Back to item 3. We never did resolve the question of detection of a
working C-compiler. IMO, that's the question that we should continue to
discuss in RT -- and the only issue that should continue to be discussed
in this particular RT. And if we think that our current method of
detecting a C-compiler is, if not perfect, good enough for the present,
then I would recommend that Paul close the ticket.
If you want to discuss the other issues mentioned above, I would
recommend either going to the RTs already open or opening a new one.
Perfect. Thanks, James!
Allison
> Andy Dougherty wrote:
> >
> > Trivial example: Configure.pl currently supports many incompatible ways to
> > say "no" (excerpts from Configure.pl --help)
> >
> > Rather than testing that each one is handled correctly, it would make
> > more sense to design and implement a single way to say "no". Then you
> > can test the daylights out of that.
>
> I have agreed (in another thread), that these should be unified. So,
> it's more a matter of TUITs than anything else.
Yes, I know, and that's part of the point. That example was intended as
an obvious example of the sort of code that I don't think needs exhaustive
test coverage.
--
Andy Dougherty doug...@lafayette.edu
> This thread and RT ticket (41168) have been under way since Jan 03 2007
> and I'm afraid that the discussion is collapsing under its own weight.
> May I make an attempt at summarizing the issues? Let's proceed from the
> outermost inwards.
[skipping to the relevant issue for this ticket]
> 3. Let's assume that we grant inter::progs more importance than other
> configuration steps. How should the absence of a working C-compiler be
> detected and reported?
Configure should try to compile and run a simple program. It should check
that the program ran, produced the desired output, and returned a
'success' exit status. If all those things don't check out, Configure
should present a message that tells the user precisely what was attempted
and what went wrong. Configure should probably offer to abort at that
point.
For comparison, here's what perl5's Configure does:
If the user specifies a non-existent C compiler (e.g. with
Configure -Dcc=NOcc) the following message is generated:
Configure: NOcc: not found
You need to find a working C compiler.
Either (purchase and) install the C compiler supplied by your OS vendor,
or for a free C compiler try http://gcc.gnu.org/
I cannot continue any further, aborting.
That's not too specific, but doesn't appear to cause too much confusion
either.
A more common occurrence (based on the mails I get) is to have a compiler,
but to have it not work as Configure expects for some reason or another.
After setting all the flags and libraries, Configure performs a sanity
check. It tries to compile and run a simple program. It checks both the
return value and the printed output. (Under at least one release of the
SFIO library, sfio's configuration script caused confusion between exit()
and _exit() with the net result that the program compiled fine, ran, and
exited with a return value of 0, but didn't actually print anything.
Accordingly, perl5's Configure tests both the output and the exit status.)
If this test fails, the following information is printed: (here I passed
in a bad library with sh Configure -Dlibs=-lnosuch
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:
#include <stdio.h>
int main() { printf("Ok\n"); return(0); }
I used the command:
cc -o try -O -I/usr/local/include -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib try.c -lnosuch
./try
and I got the following output:
ld: fatal: library -lnosuch: not found
ld: fatal: File processing errors. No output written to try
I can't compile the test program.
(The supplied flags or libraries might be incorrect.)
You have a BIG problem. Shall I abort Configure [y]
Ok. Stopping Configure.
This error message tells the user precisely what happened and gives enough
information for the user to easily reproduce (and, I hope, fix) the
> int main() { printf("Ok\n"); return(0); }
magic numbers are bad. use C89-friendly and much more expressive
C<EXIT_SUCCESS> in place of C<0>.
~jerry
If that's not sufficient, with the --fatal-step option you can now
designate one or more steps (comma-delimited list) as causing
configuration to halt upon step failure.
And if *that's* not sufficient, you can run Configure.pl with the
--fatal option, whereupon the failure of *any* configuration step will
cause all configuration to halt.
sub cc_run {
...
my $run_error;
if ( defined( $_[0] ) && length( $_[0] ) ) {
local $" = ' ';
$run_error = _run_command( "$test_exe @_", './test.out', undef,
$verbose );
}
else {
$run_error = _run_command( "$test_exe", './test.out', undef,
$verbose );
}
my $output = _slurp('./test.out');
return $output;
}
Note that nothing is ever done with $run_error. Would it be of any use
in giving a more descriptive explanation of why comfiguration might fail?
(Or, since this method is called in *many* locations, would making a
change here create more problems than it would solve?)
kid51
Correction: cc_run() is defined in lib/Parrot/Configure/Compiler.pm.
>
> I'm satisfied that the original request is resolved. There's a lot of
> discussion further down in the ticket which I /think/ can be shelved
> until whenever config is looked at down the road.
>
Agreed. I will take the ticket now and close it in a few days unless
someone registers strong objection.
kid51