From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
Cc: yocto@yoctoproject.org
Subject: Re: Requesting information on some variables
Date: Thu, 18 Oct 2012 10:20:02 +0100 [thread overview]
Message-ID: <1444424.PbzRs5XmCV@helios> (raw)
In-Reply-To: <41DEA4B02DBDEF40A0F3B6D0DDB1237946A86E2E@ORSMSX101.amr.corp.intel.com>
On Wednesday 17 October 2012 21:07:20 Rifenbark, Scott M wrote:
> Thanks for the added investigation here. The original bug report listed
> COMMON_FEATURES as an undocumented variable. I see, however, that the
> variable referred to by both you and Paul Eggleton is COMBINED_FEATURES. I
> just did a grep through my entire poky tree, which had built out the
> core-image-minimal image for the qemux86 MACHINE and came up empty for
> "COMMON_FEATURES" except where the string is part of other variables. So,
> it appears there is no COMMON_FEATURES variable.
>
> According to Paul, COMBINED_FEATURES is a list of features common to both
> MACHINE_FEATURES and DISTRO_FEATURES.
Yes, the variable is COMBINED_FEATURES.
> It also seems that the lists presented in the documentation for both valid
> distro and machine options are not really finite lists.
Correct, the list is not set in stone. People are free to add new features to
MACHINE_FEATURES and DISTRO_FEATURES in their own setups and check for them in
their own recipes/configuration files if it helps them handle different machines
they want to target or different types of distros they want to build
respectively. However, we should document all of the features we have defined
out of the box.
> But, the fact that you grep'ed out such a huge list of
> DF below shows that they far exceed the 16 features listed in the
> documentation. I'll update the preamble to the "Distro" and "Machine"
> sections in the reference manual when I get the real story on those lists.
I can try to help document all of the features. It's possible that some of
them that we refer to are effectively placeholders that don't do anything at
the moment (e.g. ipv6 in DISTRO_FEATURES).
> I don't know the relationship between "features" and "packages"... maybe it
> is a one-to-one relationship.
It's definitely not 1-1, and sometimes a feature doesn't just control the
installation of a package or packages, but influences how certain recipes are
built, e.g. it might determine whether a particular configure option is
specified within do_configure for a particular recipe.
> But, there are some other variables that
> affect packages and features (according to the documentation) that are
> considered during the build. These are the ones listed in the manual's
> glossary section:
>
> * MACHINE_ESSENTIAL_EXTRA_RDEPENDS
>
> * MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
>
> * MACHINE_EXTRA_RDEPENDS
>
> * MACHINE_EXTRA-RRECOMMENDS
>
> * DISTRO_EXTRA_RRECOMMENDS
Let's not muddy the waters too much here - these aren't directly related to
features although they are related to machine and distro configuration.
> I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't
> have it in the manual (should be added if so).
Yes, that exists and should be documented.
> Also, not sure if there are variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS
> and DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS. If those really exist, then I need
> to add them as well.
No, there are no such variables.
> Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and
> DISTRO_FEATURES set. It looks like *_FEATURES_BACKFILL, which is set in
> the bitbake.conf file, is a way to make sure a feature is always included
> as part of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific
> machine configurations (<machine>.conf) to disable a particular feature
> when it also appears with *_FEATURES_BACKFILL. So these variables add to
> the mix also.
We have added the 9.4 section on "Feature backfilling" that should cover what
these are for and how they work. If the explanation there is not clear enough
then by all means lets enhance that section and/or the entries in the glossary
for these variables, but they are at least documented now.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-10-18 9:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 15:32 Requesting information on some variables Rifenbark, Scott M
2012-10-17 15:58 ` Paul Eggleton
2012-10-17 16:08 ` Rifenbark, Scott M
2012-10-17 20:16 ` Rudolf Streif
2012-10-17 21:07 ` Rifenbark, Scott M
2012-10-18 9:20 ` Paul Eggleton [this message]
2012-10-18 9:33 ` Burton, Ross
2012-10-18 10:36 ` Burton, Ross
2012-10-18 21:39 ` Rifenbark, Scott M
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=1444424.PbzRs5XmCV@helios \
--to=paul.eggleton@linux.intel.com \
--cc=scott.m.rifenbark@intel.com \
--cc=yocto@yoctoproject.org \
/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.