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]
