From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>,
OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: purpose of variables like "base_bindir_native"?
Date: Thu, 01 Dec 2016 10:24:48 +0000 [thread overview]
Message-ID: <1480587888.28508.265.camel@linuxfoundation.org> (raw)
In-Reply-To: <alpine.LFD.2.20.1611300625420.7224@ca624034.mitel.com>
On Wed, 2016-11-30 at 06:34 -0500, Robert P. J. Day wrote:
> i'm putting together a tutorial on the structure of the native
> sysroot and how it's built and variables involved, and was poking
> around in both bitbake.conf and native.bbclass, and i'm curious about
> one or two things.
>
> i could be totally wrong but it *seems* like there's native-related
> content in bitbake.conf that could be moved over to native.bbclass to
> reduce a little of the clutter. i'm perusing bitbake.conf and it's
> hard to keep track of some of the variables just because there's both
> native- and target- related settings in there. but i'll admit i
> haven't finished my inspection.
>
> on a more specific note, in the entire oe-core layer, there are two
> references to the variable "base_bindir_native" (formatted for
> aesthetics):
>
> $ grep -rw base_bindir_native *
> meta/conf/bitbake.conf:base_bindir_native = "/bin"
> meta/conf/bitbake.conf:PATH_prepend =
> "${COREBASE}/scripts:i
> ${STAGING_BINDIR_TOOLCHAIN}:
> ${STAGING_BINDIR_CROSS}:
> ${STAGING_DIR_NATIVE}${sbindir_native}:
> ${STAGING_BINDIR_NATIVE}:
> ${STAGING_DIR_NATIVE}${base_sbindir_native}:
> ${STAGING_DIR_NATIVE}${base_bindir_native}:" <----- there
>
> so, given that that variable is set in bitbake.conf, and is only
> referenced in that same file, what's the point of making it a
> variable? doesn't hurt, of course, but when i see a variable, i
> normally assume it's because it might be modified later somewhere,
> but
> i don't see that happening here. is there a reason for it? same thing
> could be said for "base_sbindir_native" as well.
>
> thoughts?
Its really for consistency. We don't hardcode the other path
relationships and whilst that one is a minority, we've clearly decided
not to hardcode it either. The fact its not widely used compared to
some of its relatives is not really the point.
If we did hardcode it, I can imagine the question about why it wasn't
parametrised ;-).
Cheers,
Richard
prev parent reply other threads:[~2016-12-01 10:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 11:34 purpose of variables like "base_bindir_native"? Robert P. J. Day
2016-12-01 3:51 ` Khem Raj
2016-12-01 10:24 ` Richard Purdie [this message]
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=1480587888.28508.265.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=rpjday@crashcourse.ca \
/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.