[OE-core] [OE-Core][PATCH] gzip: Avoid host contamination during build

[Dan McGregor]

On May 28, 2014 5:09 PM, "Richard Purdie" <
richard.purdie at linuxfoundation.org> wrote:
>
> On Tue, 2014-05-27 at 17:38 -0600, Dan McGregor wrote:
> > From: Dan McGregor <dan.mcgregor at usask.ca>
> >
> > On systems with /bin and /usr/bin merged the gzip recipe may find grep
> > in /usr/bin, while OE puts it in /bin. Force the recipe to find grep in
> > the correct place.
> >
> > Signed-off-by: Dan McGregor <dan.mcgregor at usask.ca>
> > ---
> >  meta/recipes-extended/gzip/gzip.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-extended/gzip/gzip.inc
> > b/meta/recipes-extended/gzip/gzip.inc
> > index 920b256..57873cb 100644
> > --- a/meta/recipes-extended/gzip/gzip.inc
> > +++ b/meta/recipes-extended/gzip/gzip.inc
> > @@ -12,6 +12,8 @@ SRC_URI = "${GNU_MIRROR}/gzip/${BP}.tar.gz"
> >
> >  inherit autotools texinfo
> >
> > +EXTRA_OEMAKE = "GREP=${base_bindir}/grep"
> > +
> >  do_install_append () {
> >   # Rename and move files into /bin (FHS), which is typical place for
gzip
> >   install -d ${D}${base_bindir}
>
> My worry is what happens to gzip-native. Do we have to encode a path?
>
> Cheers,
>
> Richard
>
gzip native does encode a path, but what it encodes should probably be what
gets automatically configured. Would making the EXTRA_OEMAKE variable be
EXTRA_OEMAKE_class-target then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140529/b20edfc6/attachment-0002.html>