chromatic wrote:
# New Ticket Created by chromatic
# Please include the string: [perl #47503]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47503 >
I've seen a lot of test failures under t/configure/*.t lately where linking
failed because I don't have libgdbm installed.
Are you getting failures in test files other than the one you reported
(auto::msvc, IIRC) and the 3 that Andy D reported?
The vendor Perl has libgdbm
in its libs setting within Config.pm, so any code that probes my Perl 5
configuration may think that it's okay to link against libgdbm even though it
doesn't exist on my system.
config::init::defaults pulls the libs setting out of the Perl 5 configuration
and various tests of the Parrot configuration process use
config::init::defaults to set up the environment for testing.
When these tests attempt to compile and link programs, they may fail because
the Perl 5 configuration may not reflect the actual run-time environment of
the code.
Yes, they may fail there, but only because the *only* configuration step
I ran in a particular test file was config::init::defaults. For most
test files and on many systems, that has sufficed.
Parrot::Config::Generated is a much more reliable source of information, and
if the tests truly need information about the local system for compiling and
linking purposes, they should fetch the information from there, not from the
Perl 5 configuration which does not necessarily reflect the state of the
local machine.
I can imagine an objection to this suggestion, specifically "But these tests
should be runnable without having previously configured Parrot! We cannot
rely on the configuration process working correctly unless we can test that
process!"
And that is precisely my objection. Parrot::Config::Generated is not
available until after you've configured. You can't use it to test the
configuration system before you've run Configure.pl (as you would by
running, say, 'perl Configure.pl --test=configure').
I've been working on this problem and getting valuable feedback from
Bernard. I've developed a way of using Parrot::Configure::Trace to more
accurately identify the state of the Parrot::Configure object at each
point in the configuration process, thereby enabling us to write more
precisely targeted tests.
I would ask you to try out these patches as I submit them and give me
feedback.
Thank you very much.
kid51
