# 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. 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. 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!" Yet if we cannot rely on the accuracy of the tests, they provide little value. Clearly Parrot's configuration process works on my machine, as demonstrated by the fact that Parrot builds successfully and passes all functional tests. Yet the configuration test fails with a false negative. To get the maximum value out of the tests of the configuration system, the tests must be robust and reliable. Failures should indicate actual problems of behavior. I don't believe that we can rely on these tests until we remove the assumption that the local Perl 5 configuration is correct for Parrot. If that means that some of these tests cannot run from an unconfigured Parrot, so be it. Our goal is to improve the quality and portability and debuggability of our configuration process. -- c
