<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 7:55 AM, Mike Crowe <span dir="ltr"><<a href="mailto:mac@mcrowe.com" target="_blank">mac@mcrowe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday 30 April 2015 at 07:39:25 -0700, Christopher Larson wrote:<br>
> On Thu, Apr 30, 2015 at 7:28 AM, Mike Crowe <<a href="mailto:mac@mcrowe.com">mac@mcrowe.com</a>> wrote:<br>
</span><span class="">> > Unfortunately passing "-e" subtly changes the behaviour of libcap's<br>
> > Make.Rules under recursive make when prefix="" (which it is for us since<br>
> > we're using meta-micro.)<br>
<br>
</span>[snip]<br>
<span class=""><br>
> Given our use of make -e (with MAKEFLAGS= to try to prevent it from flowing<br>
> into submakes) was always a hack to try to let things "just work", I think<br>
> wherever possible we should stop relying on it, and explicitly pass<br>
> everything the way that particular make-based buildsystem expects,<br>
> personally. Better to be explicit than to rely on implicit "magic".<br>
> Further, that behavior encourages recipe maintainers to not even read the<br>
> buildsystem of the project they're creating a recipe for, which often leads<br>
> to problems down the road..<br>
<br>
</span>I completely agree, but what is the best way to avoid "-e". Is there ever<br>
likely to be anything else in EXTRA_OEMAKE that would need to be preserved?<br>
<br>
I notice that autotools.bbclass just sets EXTRA_OEMAKE = "" so perhaps it's<br>
relatively safe to just assign it directly.</blockquote></div><br>Yeah, generally it's safe. The recipe knows more about a make-based buildsystem than any of our classes do anyway, since there are no real standards. Autotools is a different story, of course.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>