On Thu, 25 Jun 2009, Andy Dougherty wrote:
On Tue, 23 Jun 2009, Jeff Horwitz wrote:
On Mon, 22 Jun 2009, James E Keenan wrote:
Since jhorwitz asked me about this just now at YAPC|10 Parrot BOF, a data
point:
./parrot_config --dump | grep '$('
cat => '$(PERL) -MExtUtils::Command -e cat'
chmod => '$(PERL) -MExtUtils::Command -e ExtUtils::Command::chmod'
cp => '$(PERL) -MExtUtils::Command -e cp'
libparrot => '$(LIBPARROT_SHARED)'
libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)'
libparrot_shared_alias => 'libparrot$(SHARE_EXT)'
libparrot_soname => '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)'
mkpath => '$(PERL) -MExtUtils::Command -e mkpath'
mv => '$(PERL) -MExtUtils::Command -e mv'
rm_f => '$(PERL) -MExtUtils::Command -e rm_f'
rm_rf => '$(PERL) -MExtUtils::Command -e rm_rf'
touch => '$(PERL) -MExtUtils::Command -e touch'
i ended up working around this problem, so it's not as critical for me
anymore. that said, i decided to dig a little deeper for the greater good. i
found that the Makefile-style variables are hidden in the OS hints files. it
doesn't make much sense to expand them there, but we might want to consider
doing it while generating parrot_config. i already wrote the expansion code
for mod_parrot -- i'll see if i can shoehorn it in.
I don't know what, precisely "this problem" is, but permit me a general
observation: Before adding in yet another layer of variable expansion,
it might be worthwhile to step back as you did and ask where these
variables came from, and question why they exist at all.
Most of them (cat, chmod, cp, mkpath, mv, rm_f, rm_rf, and touch) are
documented in config/init/defaults.pm as '#some utilities in Makefile'.
I don't know whether or not they are a problem. They are documented
as variables to be used in a Makefile, and they work quite well in
that context. However, they are also sufficiently vanilla commands that
expanding out the $(PERL) would probably make little or no difference.
It also may not be at all relevant, since I'm unclear whether you are
trying to use these utility commands outside of a Makefile. If you are,
you may be better off just using the ExtUtils::Command versions directly.
The remaining ones (libparrot, libparrot_shared, libparrot_shared_alias,
and libparrot_soname) look to me as if they can (and should) simply be
expanded by Configure.pl in the first place.
i think we're on the same page here.
"the problem" is that i am indeed using these outside of a Makefile. so
will things like "configure" if it tries to detect parrot and its headers
and libraries -- it doesn't bother with Makefiles either. so unless
parrot_config is being used internally to generate Makefiles, its
audience is purely external and the variables should be expanded for them.
*when* and *where* they are expanded is an entirely different discussion,
but one we'll need to have.
in the case of mod_parrot i'm only concerned about the libparrot variables
in particular, but if we do this, we should still expand $(PERL) and any
other variables for consistency.
-jeff
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
