[OE-core] [PATCH v2 01/25] bitbake.conf: support for merged usr with DISTRO_FEATURE usrmerge

[Patrick Ohly]

On Wed, 2017-06-07 at 12:52 +0100, Richard Purdie wrote:
> On Wed, 2017-02-22 at 10:26 +0200, Amarnath Valluri wrote:
> > From: Joshua Lock <joshua.g.lock at intel.com>
> > 
> > Modify bindir, libdir and sbindir to be exec_prefix/$d, rather than
> > base_prefix/$d, when the usrmerge DISTRO_FEATURE is enabled.
> > 
> > Signed-off-by: Joshua Lock <joshua.g.lock at intel.com>
> > ---
> >  meta/conf/bitbake.conf | 12 ++++++++----
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> I was asked to clarify the status of this series. We've taken many of
> the changes but the core changes to bitbake.conf haven't been merged.
> 
> Ross/I discussed it and we both feel that the bitbake.conf make the
> file pretty unreadable. We'd therefore like to see this implemented as
> a .inc file which gets included when the relevant DISTRO_FEATURE is set
> (or could just be included by the appropriate distro configs). This
> .inc file would then simply override the paths. I believe this would be
> a lot more readable than the current approach which is a key concern in
> the core config.
> 
> The merge of the rest of this feature is therefore pending on the
> development of such a patch, or a discussion convincing Ross/I why we
> shouldn't take that approach for some reason.

Such a .inc file would have to be included after the "Include the rest
of the config files." section, because DISTRO_FEATURES only has its
final value (?) at that point. One also needs the patch that I
coincidentally just sent today to the bitbake list which allows
including such a file only when "usrmerge" is in DISTRO_FEATURES.

Would that be okay?

One downside is that code using the variables earlier will just see the
non-usrmerge version, with no indication in "bitbake -e" that the value
might have been different in the middle of parsing. The if check in the
proposed patch has the same effect on the actual values, but at least it
shows up in "bitbake -e". This is not a particularly strong argument
either way, I just wanted to mention it.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.