On Mon Nov 12 10:43:02 2007, doughera wrote: > [snip] > > After looking into it some, the problem seems to be that these tests > rely on init::defaults. That simply won't work if the configuration > being used to build parrot is sufficiently different from that which > was used to build perl. That's what happened to me in this case. > > This probably doesn't show up often because nearly everyone building > parrot right now uses the same configuration as was used to build > perl.
Ah, Andy, I can always count on you to run tests in a way that they fail and point up hidden assumptions! ;-) > However, that's not necessarily the norm. Vendors such as Sun supply > a perl pre-built with their compiler, but many end users have gcc > installed instead. > > If a test for a configuration step relies on certain Config values, > the > only correct approach is to use the Config values determined by > Configure.pl. There is no guarantee that the init::defaults values > will > work. They may well have been changed, either by the user (via --ask > or > command line overrides) or by the Configure.pl system itself. > Agreed. This first became apparent in the discussion found in https://rt.perl.org/rt3/Ticket/Display.html?id=47127, particularly http://tinyurl.com/26mobo. As I wrote there, I've been trying to write tests for the config steps so that they don't take excessive time or resources -- but that has to be balanced against the fact that later steps depend on earlier steps in which values set in init::defaults may have been subsequently overridden. I will try to repair these tests, and I would ask that you give me rapid feedback on the patches I post, as I cannot replicate the errors you have pointed out. But I also would like to note that this points out that our reliance on Perl 5's %Config is showing its age. kid51
