All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
	poky <poky@yoctoproject.org>
Subject: Re: [poky] [PATCH] flex/bison: Don't hardcode M4 path
Date: Wed, 04 Jan 2012 16:18:54 +0000	[thread overview]
Message-ID: <1325693934.20759.19.camel@ted> (raw)
In-Reply-To: <1325643628.24646.13.camel@lenny>

On Tue, 2012-01-03 at 21:20 -0500, Colin Walters wrote:
> On Tue, 2012-01-03 at 16:53 -0800, Saul Wold wrote:
> > > The flex and bison configure scripts use AC_PATH_PROG to get a
> > > full path to m4 and embed this in config.h (and then to the
> > > generated binary), but this blows up when the m4 binary is in a
> > > temporary staging directory.
> > >
> > > Since we are always shipping GNU m4, just set M4=m4 at configure
> > > time so we don't use a hardcoded path.
> > >
> > > This is an equivalent to what already exists in autoconf.bb.
> > >
> > >
> > This should really be posted to openembedded-core@lists.openembedded.org.
> 
> I CC'd, hopefully won't be rejected as I'm not yet a subscriber.
> 
> > Don't you loose the setting of BISON_PKGDATADIR in this case?  Does that 
> > need to be poart of the EXTRA_OECONF?
> 
> Good catch - I'll double check, but I doubt it's necessary.  From the
> bison source:
> 
> char const *
> compute_pkgdatadir (void)
> {
>   char const *pkgdatadir = getenv ("BISON_PKGDATADIR");
>   return pkgdatadir ? pkgdatadir : PKGDATADIR;
> }
> 
> For us though PKGDATADIR should be enough I think.

For on target device development, yes. For use in bison-native, its not
enough unfortunately as it gets added into the sstate packages and those
may end up installed at a different location.

I like the idea of simplifying looking for m4 though.

Cheers,

Richard




WARNING: multiple messages have this Message-ID (diff)
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
	poky <poky@yoctoproject.org>
Subject: Re: [PATCH] flex/bison: Don't hardcode M4 path
Date: Wed, 04 Jan 2012 16:18:54 +0000	[thread overview]
Message-ID: <1325693934.20759.19.camel@ted> (raw)
In-Reply-To: <1325643628.24646.13.camel@lenny>

On Tue, 2012-01-03 at 21:20 -0500, Colin Walters wrote:
> On Tue, 2012-01-03 at 16:53 -0800, Saul Wold wrote:
> > > The flex and bison configure scripts use AC_PATH_PROG to get a
> > > full path to m4 and embed this in config.h (and then to the
> > > generated binary), but this blows up when the m4 binary is in a
> > > temporary staging directory.
> > >
> > > Since we are always shipping GNU m4, just set M4=m4 at configure
> > > time so we don't use a hardcoded path.
> > >
> > > This is an equivalent to what already exists in autoconf.bb.
> > >
> > >
> > This should really be posted to openembedded-core@lists.openembedded.org.
> 
> I CC'd, hopefully won't be rejected as I'm not yet a subscriber.
> 
> > Don't you loose the setting of BISON_PKGDATADIR in this case?  Does that 
> > need to be poart of the EXTRA_OECONF?
> 
> Good catch - I'll double check, but I doubt it's necessary.  From the
> bison source:
> 
> char const *
> compute_pkgdatadir (void)
> {
>   char const *pkgdatadir = getenv ("BISON_PKGDATADIR");
>   return pkgdatadir ? pkgdatadir : PKGDATADIR;
> }
> 
> For us though PKGDATADIR should be enough I think.

For on target device development, yes. For use in bison-native, its not
enough unfortunately as it gets added into the sstate packages and those
may end up installed at a different location.

I like the idea of simplifying looking for m4 though.

Cheers,

Richard



  reply	other threads:[~2012-01-04 16:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-03 23:50 [PATCH] flex/bison: Don't hardcode M4 path Colin Walters
2012-01-04  0:53 ` [poky] " Saul Wold
2012-01-04  0:53   ` Saul Wold
2012-01-04  2:20   ` [poky] " Colin Walters
2012-01-04  2:20     ` Colin Walters
2012-01-04 16:18     ` Richard Purdie [this message]
2012-01-04 16:18       ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1325693934.20759.19.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@yoctoproject.org \
    --cc=walters@verbum.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.