On Sat, Mar 05, 2011 at 08:16:51AM +0100, Landry Breuil wrote:
> On Sat, Mar 05, 2011 at 01:21:51AM +0100, Pascal Stumpf wrote:
> > On Fri, Mar 04, 2011 at 10:00:51PM +0100, Landry Breuil wrote:
> > > On Fri, Mar 04, 2011 at 05:28:08PM +0100, Pascal Stumpf wrote:
> > > Oh, and you
> > > diff has some /usr/local hardcoded which should use LOCALBASE+SUBST_CMD.
> > It's only in the diff by chance, but since it's the only case where a
> > hardcoded /usr/local will not get overridden by --prefix=, I fixed it
> > anyway.
> 
> > -ONLY_FOR_ARCHS=    i386 amd64
> > +ONLY_FOR_ARCHS=    i386 amd64 macppc arm mips64
> 
> kili tested mips64el, not mips64... anyway, given that we don't know for
> other archs, and that so far it only fails in regress on spar64, i think
> we should use BROKEN-sparc64 instead to let a chance to other archs.
Ok. :)
> 
> > +post-patch:
> > +   perl -pi -e 's#/usr/local#${LOCALBASE}#' \
> > +           ${WRKSRC}/config/init/hints/openbsd.pm
> 
> > +     my $ldflags = $conf->data->get('ldflags');
> > +     if ( $ldflags !~ m|-L/usr/local/lib\b| ) {
> > +         $ldflags .= ' -L/usr/local/lib';
> 
> That should be the other way round. Patch to use ${LOCALBASE}, and if
> it's not taken as an environment variable during the build, use
> SUBST_CMD on the .pm file during pre-configure, which will take care of
> replacing ${LOCALBASE} by its real value.
There's not much difference effectively (unless I'm missing something
...), or is there any kind of policy on how to do such replacements?

> But since that's not in a change made by the patch, i'm not sure we
> should care so much about it... upstream just wants to add usr/local/lib
> to ldflags if it's not already there..
It will probably do neither harm nor good even for non-standard
${LOCALBASE}, but I think it's reasonable to assume that by 'add
/usr/local/lib to $ldflags if it's not already there' they meant 'add
${LOCALBASE}/lib if it's not already there'. I think parrot's
configure/make system does not even know about ${LOCALBASE} (only
${PREFIX}), so hardcoding the most common value for ${LOCALBASE} was
maybe the only way to go ...

Pascal

Reply via email to