[OE-core] [PATCH] bitbake.conf, module.bbclass: Support opting out of legacy EXTRA_OEMAKE

[Martin Jansa]

On Fri, Nov 06, 2015 at 07:59:32AM -0700, Christopher Larson wrote:
> On Fri, Nov 6, 2015 at 6:18 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> 
> > On Fri, Nov 06, 2015 at 10:30:04AM +0000, Mike Crowe wrote:
> > > On Friday 06 November 2015 at 01:16:46 -0800, Andre McCurdy wrote:
> > > > On Thu, Nov 5, 2015 at 6:47 AM, Mike Crowe <mac at mcrowe.com> wrote:
> > > > > Give recipes and classes the ability to opt out of EXTRA_OEMAKE
> > > > > containing the legacy value without removing other recipe-specific or
> > > > > local additions.
> > > >
> > > > Isn't this possible already from within a recipe or class by using
> > > >
> > > >   EXTRA_OEMAKE = ...
> > > >
> > > > instead of
> > > >
> > > >   EXTRA_OEMAKE += ...
> > > >
> > > > ie what autotools.bbclass, kernel.bbclass and many recipes do already.
> > > >
> > > > For the specific case of module.bbclass, changing the EXTRA_OEMAKE
> > > > assignment to '=' might require some recipes to be tweaked to so that
> > > > they "inherit module" before adding their own options to EXTRA_OEMAKE,
> > > > but it seems like a cleaner solution?
> > >
> > > It would be, but I was afraid of what I might break. I suspect that there
> > > are many unseen third-party and local recipes that inherit
> > module.bbclass.
> > >
> > > It would be great to get to the point that EXTRA_OEMAKE is empty by
> > default
> > > but I imagine that the experts are already aware of the difficulties with
> > > doing this which is why the current value has lasted so long.
> >
> > Is it really good goal to get rid of "-e"?
> >
> > I know that the environment used in bitbake tasks is already well
> > defined and controlled, but I still find a bit more control with -e to
> > be useful in many cases.
> >
> > I know I'll be able to return -e where useful, but what's the main
> > advantage of removing it from default?
> 
> 
> The original goal of the default EXTRA_OEMAKE was to let us keep our
> recipes as minimal as possible and have as many "Just Work" out of the box
> as possible. It succeeded in this goal. The problem is the corner cases,
> and more importantly, it encourages people creating recipes for custom
> make-based buildsystems to just try building it and hack at it till it
> works, rather than reading the makefiles, determining which variables to
> pass in, in what form, and customizing EXTRA_OEMAKE to explicitly pass
> what's needed in the appropriate ways.
> 
> That's my biggest concern with it, other than the aforementioned occasional
> breakage. It's implicit, automatic, rather than explicit, and tacitly
> encourages ignorance of the buildsystem in question.

I'm sorry I was reading it backwards (I should never reply on e-mails
before first morning coffee).

Removing -e from default value is good goal and I like it :)

e.g. in qmake5_base.bbclass it saved me a lot of headaches with generated
Makefiles reading variables from env which were supposed to be set
correctly by qmake.

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151106/e9d8e9f5/attachment-0002.sig>