Ticket #797 (closed RFC: fixed)
Eliminate need to expand Makefile variables in parrot_config and other external programs
Description
This ticket represents conversion of a thread on parrot-dev into a Trac ticket. I am presenting the original post as well as excerpts from the follow-up discussion.
Jeff Horwitz wrote on 5/17/09:"
in #parrotsketch last week i brought up the interesting output of parrot_config, and allison asked for an RFC. here it is.
most parrot_config values are literal strings, simple enough. for example:
ldflags => ' -L/usr/local/lib' libdir => '/usr/local/lib' libexecdir => '/usr/local/libexec'
others, however, contain Makefile variables that would need to be expanded before use. for example:
libparrot => '$(LIBPARROT_SHARED)' libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)' libparrot_shared_alias => 'libparrot$(SHARE_EXT)' libparrot_soname => '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)'
some are simple, but others, such as libparrot, would require several iterations to expand. when i want to know the name of the shared libparrot, the last thing i expect to see is libparrot$(SHARE_EXT).$(SOVERSION). it makes me work that much harder for a simple bit of information.
it also forces the use of a Makefile. for most projects that won't be a problem, but what if i want these values during a configuration stage, pre-Makefile? that's how GNU configure scripts work, and embedded variables would break it horribly. outside of configure, i could write something to expand the variables, but why not do that for the programmer in the config itself? and what if i have my own $(SOVERSION)? i have to rename it now?
so, to the point. is there a reason we're using embedded Makefile variables in parrot_config values? my guess is that it's legacy, and if that's the case i strongly recommend expanding these variables. the only consequence i could think of is what if a value changes? the answer here is to reconfigure -- if one of these values changes, you should probably be reconfiguring anyway.
comments please!
-jeff
Jim Keenan wrote on 6/22/09:
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'
Jeff Horwitz wrote on 6/23/09:
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.
Allison Randal wrote on 6/24/09:
Yes, having parrot_config pre-process these substitutions is a good idea. (We could add a command-line flag to turn off preprocessing when the raw values are really needed.)
Andy Dougherty wrote on 6/25/09:
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.
Andy Dougherty further wrote on 6/25/09:
If you look for SHARE_EXT, you'll pick up lots of lines like this: (I've collapsed spaces for clarity)
config/init/hints/openbsd.pm:
libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)',
I am proposing replacing that by
libparrot_shared => 'libparrot' .
$conf->data->get('share_ext')
. "." .
$conf->data->get('VERSION')
(since soversion isn't currently defined by Configure.pl, but ends up being VERSION, i.e., something like 1.3.0.)
The issue is Config variables getting set to stuff like$(STUFF) that will have to be further expanded by the Makefile and also, independently, and redundantly, expanded by the hypothetical parrot_config creation utility. My idea was to not do that. Simply have perl write the expanded values into Generated.pm in the first place. Then nobody has to expand or convert anything.
Attachments
-
libparrot.interim.patch
(2.4 KB) - added by jkeenan
13 years ago.
- patch so far for Linux only
