On Tue, 11 Dec 2007, Jim Keenan wrote: > >From: Andy Dougherty via RT > >Date: 2007/12/11 Tue AM 08:38:17 CST > >Subject: Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 > >config steps > > > > >I don't think this will work. Specifically, to conduct a "basic test of > >that compiler's functioning" you need to compile *and link* a program, but > >you haven't picked a linker yet. > > Andy, that's what I thought at first, and you may well be correct. > > However, as I read the code in the current HEAD of > config/inter/progs.pm, the *only* variable passed to the internal > test_compiler subroutine is $cc (line 130). $cc is assigned to much > farther up inside the runstep() method (lines 61-62), and immediately > thereafter assigned to the 'cc' argument in the Parrot::Configure object > (line 63). All the other values you mention are assigned between lines > 64 and 130, but, AFAICT, none of those assignments depend on either $cc > or the value assigned to 'cc' inside the configuration object. The > test_compiler() method, *as written*, does not appear to depend at all > on any of the other values located on the system or selected at the > prompt, and it does not appear to depend on the Parrot::Configure > object. If so, then the refactoring I suggested is plausible.
I think you're missing three things: 1. test_compiler() calls cc_build(), which most definitely does need to use $ccflags and $link. 2. The settings of things like ccflags and ldflags *could* depend on the compiler, even if the current inter/progs.pm file doesn't actually implement that. Recognizing that some compilers are available on more than one platform, it makes sense to handle them in inter/progs.pm, not duplicate them in different hints files. For now, though, such information is buried in various hints files. For example, look at hints/linux.pm -- three different compilers are dealt with there. 3. Triggers (or callbacks) can change the flow in hidden ways. For example, the solaris hints file sets the value of $link depending on whether the user is using cc or gcc. > Of course, it may very well be that test_compiler() was misconceived all > along and that it *should* have been passed the current state of the > Parrot::Configure object ($conf). What do you think? cc_build() consults the global $conf, and hence doesn't need it passed in. I would certainly agree that the flow of information isn't well controlled here. Passing the object in sometimes and other times consulting the global object does seem like a recipe for confusion. It might make sense to always do one or the other. -- Andy Dougherty [EMAIL PROTECTED]