[OE-core] [PATCH 0/3] Remove unhelpful default value of EXTRA_OEMAKE

[Richard Purdie]

On Tue, 2016-02-02 at 21:04 +0000, Mike Crowe wrote:
> On Tuesday 02 February 2016 at 16:01:14 +0000, Richard Purdie wrote:
> > On Tue, 2016-02-02 at 14:49 +0000, Mike Crowe wrote:
> > > bitbake.conf currently contains:
> > > 
> > > EXTRA_OEMAKE = "-e MAKEFLAGS="
> > > 
> > > Back in November[1] I submitted a patch that allowed this default
> > > value to be overridden without affecting anything else that was
> > > appended to it. I received feedback that the default value was no
> > > longer useful and that it would be good to get rid of it.
> > > 
> > > So, this patch series fixes the two recipes that still appear to
> > > be
> > > relying on the previous default and then makes the default
> > > EXTRA_OEMAKE = "". After these changes core-image-sato builds
> > > successfully for me (although I have not run it.)
> > > 
> > > Mike.
> > > 
> > > [1] 
> > > http://lists.openembedded.org/pipermail/openembedded-core/2015-No
> > > vember/112393.html
> > 
> > This is a pretty major change and we likely need a bit more of an
> > idea
> > of impact.
> 
> I agree.
> 
> > Which architectures did you test? Often, x86 is a bad choice here
> > and
> > we'd need something cross (arm/mips/ppc) to ensure it really is
> > doing
> > the right things. We also need to assess a bit more than just sato.
> > We
> > can run this up on the autobuilder and see what happens.
> 
> I've compile-tested qemux86 and qemuarm for core-image-sato. qemumips
> is
> building now.
> 
> We've been running with the previous version of the patch with our
> code for
> a while but now I look more closely that solution didn't have
> anywhere near
> as wide an impact so I'll switch us over to using these patches. That
> will
> runtime-test a few real mips and arm targets (and even x86 and x86-64
> to a
> limited extent) but only with our customised set of packages.

Thanks. Please do mention what tests have passed/failed just so I can
build some idea of the risk of the patch and decide if/as/when the
right time to merge it is.

> > A post to the architecture list is probably needed so everyone
> > knows
> > this is happening (or at least being considered).
> 
> I'll do that once I've finished this round of testing. Would it be
> best to
> just post a general overview or the complete patch series?

The general overview and main patch is fine. I will likely merge any
fixups like the two in this series as they become available since they
don't have an adverse affect as far as I can tell.

> > I do worry how much of meta-oe may be affected by this.
> 
> We don't use meta-oe. I could have a look at trying some builds over
> the
> weekend. Luckily any breakage will be easy to fix, but that doesn't
> really
> help if hundreds of packages are affected!

Right, I really just need an idea of whether its going to cause
problems and a rough idea of scale. I will run this on the Yocto
Project autobuilder but we're pushed for bandwidth at the moment so it
may not be until the weekend.

Cheers,

Richard