#797: Eliminate need to expand Makefile variables in parrot_config and other
external programs
---------------------+------------------------------------------------------
Reporter: jkeenan | Owner:
Type: RFC | Status: new
Priority: normal | Milestone:
Component: none | Version: 1.3.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
---------------------+------------------------------------------------------
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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/797>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
