All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: Ross Burton <ross.burton@intel.com>,
	openembedded-core@lists.openembedded.org
Subject: libcap: make -e causing trouble
Date: Thu, 30 Apr 2015 15:28:42 +0100	[thread overview]
Message-ID: <20150430142842.GA19899@mcrowe.com> (raw)

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.


             reply	other threads:[~2015-04-30 14:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 14:28 Mike Crowe [this message]
2015-04-30 14:39 ` libcap: make -e causing trouble Christopher Larson
2015-04-30 14:55   ` Mike Crowe
2015-04-30 15:32     ` Christopher Larson

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=20150430142842.GA19899@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@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.