[OE-core] [PATCH] bitbake.conf, module.bbclass: Support opting out of legacy EXTRA_OEMAKE
Christopher Larson
clarson at kergoth.com
Fri Nov 6 14:59:32 UTC 2015
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.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151106/d9efd965/attachment-0002.html>
More information about the Openembedded-core
mailing list