libcap: make -e causing trouble

libcap: make -e causing trouble

[Mike Crowe]

oe-core 51540b64f62234c145fc32cfa3fbbaaebbeece08 altered libcap.inc (at the
time) to append to EXTRA_OEMAKE rather than assign to it. The default value
for EXTRA_OEMAKE contains "-e". This means that the change caused "-e" to
be passed to make for the first time.

Unfortunately passing "-e" subtly changes the behaviour of libcap's
Make.Rules under recursive make when prefix="" (which it is for us since
we're using meta-micro.) Here's a snippet of Make.rules:

ifdef prefix
exec_prefix=$(prefix)
lib_prefix=$(exec_prefix)
inc_prefix=$(lib_prefix)
man_prefix=$(prefix)/share
else
prefix=/usr
exec_prefix=
lib_prefix=$(exec_prefix)
inc_prefix=$(prefix)
man_prefix=$(prefix)/share
endif

Without "-e" the prefix comes from the command line in both the parent and
submakes. This takes precedence over any attempt to reassign it with a
simple "=" operation so the headers are correctly installed in (empty
string)/include.

With "-e" the prefix still comes from the command line in the parent make
but from the environment in the submake. The attempt to assign it fails in
the parent make as before, but not in the submake so the headers are
installed incorrectly in /usr/include.

In all four cases the "ifdef prefix" else clause is executed.

The quick-and-easy fix for this is simply to pass prefix="${prefix}/" but
it's really just working around the problem.

Alternatively we could go back to assigning EXTRA_OEMAKE rather than
appending to it.

What would be the preferred course of action?

Thanks.

Mike.

Re: libcap: make -e causing trouble

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

On Thu, Apr 30, 2015 at 7:28 AM, Mike Crowe <mac@mcrowe.com> wrote:

> oe-core 51540b64f62234c145fc32cfa3fbbaaebbeece08 altered libcap.inc (at the
> time) to append to EXTRA_OEMAKE rather than assign to it. The default value
> for EXTRA_OEMAKE contains "-e". This means that the change caused "-e" to
> be passed to make for the first time.
>
> Unfortunately passing "-e" subtly changes the behaviour of libcap's
> Make.Rules under recursive make when prefix="" (which it is for us since
> we're using meta-micro.) Here's a snippet of Make.rules:
>
> ifdef prefix
> exec_prefix=$(prefix)
> lib_prefix=$(exec_prefix)
> inc_prefix=$(lib_prefix)
> man_prefix=$(prefix)/share
> else
> prefix=/usr
> exec_prefix=
> lib_prefix=$(exec_prefix)
> inc_prefix=$(prefix)
> man_prefix=$(prefix)/share
> endif
>
> Without "-e" the prefix comes from the command line in both the parent and
> submakes. This takes precedence over any attempt to reassign it with a
> simple "=" operation so the headers are correctly installed in (empty
> string)/include.
>
> With "-e" the prefix still comes from the command line in the parent make
> but from the environment in the submake. The attempt to assign it fails in
> the parent make as before, but not in the submake so the headers are
> installed incorrectly in /usr/include.
>
> In all four cases the "ifdef prefix" else clause is executed.
>
> The quick-and-easy fix for this is simply to pass prefix="${prefix}/" but
> it's really just working around the problem.
>
> Alternatively we could go back to assigning EXTRA_OEMAKE rather than
> appending to it.
>
> What would be the preferred course of action?
>

Given our use of make -e (with MAKEFLAGS= to try to prevent it from flowing
into submakes) was always a hack to try to let things "just work", I think
wherever possible we should stop relying on it, and explicitly pass
everything the way that particular make-based buildsystem expects,
personally. Better to be explicit than to rely on implicit "magic".
Further, that behavior encourages recipe maintainers to not even read the
buildsystem of the project they're creating a recipe for, which often leads
to problems down the road..
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

Re: libcap: make -e causing trouble

[Mike Crowe]

On Thursday 30 April 2015 at 07:39:25 -0700, Christopher Larson wrote:
> On Thu, Apr 30, 2015 at 7:28 AM, Mike Crowe <mac@mcrowe.com> wrote:
> > Unfortunately passing "-e" subtly changes the behaviour of libcap's
> > Make.Rules under recursive make when prefix="" (which it is for us since
> > we're using meta-micro.)

[snip]

> Given our use of make -e (with MAKEFLAGS= to try to prevent it from flowing
> into submakes) was always a hack to try to let things "just work", I think
> wherever possible we should stop relying on it, and explicitly pass
> everything the way that particular make-based buildsystem expects,
> personally. Better to be explicit than to rely on implicit "magic".
> Further, that behavior encourages recipe maintainers to not even read the
> buildsystem of the project they're creating a recipe for, which often leads
> to problems down the road..

I completely agree, but what is the best way to avoid "-e". Is there ever
likely to be anything else in EXTRA_OEMAKE that would need to be preserved?

I notice that autotools.bbclass just sets EXTRA_OEMAKE = "" so perhaps it's
relatively safe to just assign it directly.

Thanks.

Mike.

Re: libcap: make -e causing trouble

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Thu, Apr 30, 2015 at 7:55 AM, Mike Crowe <mac@mcrowe.com> wrote:

> On Thursday 30 April 2015 at 07:39:25 -0700, Christopher Larson wrote:
> > On Thu, Apr 30, 2015 at 7:28 AM, Mike Crowe <mac@mcrowe.com> wrote:
> > > Unfortunately passing "-e" subtly changes the behaviour of libcap's
> > > Make.Rules under recursive make when prefix="" (which it is for us
> since
> > > we're using meta-micro.)
>
> [snip]
>
> > Given our use of make -e (with MAKEFLAGS= to try to prevent it from
> flowing
> > into submakes) was always a hack to try to let things "just work", I
> think
> > wherever possible we should stop relying on it, and explicitly pass
> > everything the way that particular make-based buildsystem expects,
> > personally. Better to be explicit than to rely on implicit "magic".
> > Further, that behavior encourages recipe maintainers to not even read the
> > buildsystem of the project they're creating a recipe for, which often
> leads
> > to problems down the road..
>
> I completely agree, but what is the best way to avoid "-e". Is there ever
> likely to be anything else in EXTRA_OEMAKE that would need to be preserved?
>
> I notice that autotools.bbclass just sets EXTRA_OEMAKE = "" so perhaps it's
> relatively safe to just assign it directly.


Yeah, generally it's safe. The recipe knows more about a make-based
buildsystem than any of our classes do anyway, since there are no real
standards. Autotools is a different story, of course.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2247 bytes --]