All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: Saul Wold <sgw@linux.intel.com>
Cc: poky <poky@yoctoproject.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [poky] [PATCH] flex/bison: Don't hardcode M4 path
Date: Tue, 03 Jan 2012 21:20:27 -0500	[thread overview]
Message-ID: <1325643628.24646.13.camel@lenny> (raw)
In-Reply-To: <4F03A316.2070305@linux.intel.com>

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.






WARNING: multiple messages have this Message-ID (diff)
From: Colin Walters <walters@verbum.org>
To: Saul Wold <sgw@linux.intel.com>
Cc: poky <poky@yoctoproject.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] flex/bison: Don't hardcode M4 path
Date: Tue, 03 Jan 2012 21:20:27 -0500	[thread overview]
Message-ID: <1325643628.24646.13.camel@lenny> (raw)
In-Reply-To: <4F03A316.2070305@linux.intel.com>

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.





  reply	other threads:[~2012-01-04  2:33 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   ` Colin Walters [this message]
2012-01-04  2:20     ` Colin Walters
2012-01-04 16:18     ` [poky] " Richard Purdie
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=1325643628.24646.13.camel@lenny \
    --to=walters@verbum.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@yoctoproject.org \
    --cc=sgw@linux.intel.com \
    /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.