On Dec 11, 2007 12:40 PM, Andy Dougherty <[EMAIL PROTECTED]> wrote: > 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. > hints/linux.pm should really have separate flags for even g++, since some warnings just don't work on g++.
I think it would be good if we could break out compilers separately from the operating system. This is especially useful for Sun Studio, where ccflags cross operating systems. Intel C tends to follow what the primary system compilers, but it still runs on three distinct operating system with some slight differences across the environments. Steve Peters [EMAIL PROTECTED]
