On Thu, 25 Jun 2009, James E Keenan wrote:
> 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 '$('
> [snip]
> > > > libparrot => '$(LIBPARROT_SHARED)'
> > > > libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)'
> > > > libparrot_shared_alias => 'libparrot$(SHARE_EXT)'
> > > > libparrot_soname => '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)'
> [snip]
> >
> > 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.
> >
>
> Let me see if I understand what expansion by Configure.pl would entail.
>
> Let's look at just one of these Make variables: $(SHARE_EXT)
>
> grepping the config/ directory, I get:
>
> $ fns config | xargs grep -n share_ext
That's not really relevant. You should really look for SHARE_EXT,
not share_ext.
I guess I didn't explain clearly what I had in mind.
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.
> Am I on the right track? Messing with those makefile templates doesn't seem
> very elegant or maintainable to me, at first glance.
I think what I propose is, ultimately, simpler.
--
Andy Dougherty [email protected]
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
