[OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package

[Darren Hart]

On Fri, 2013-11-22 at 12:49 +0800, jhuang0 wrote:
> 
> On 11/22/2013 10:45 AM, Darren Hart wrote:
> > On Wed, 2013-11-20 at 09:40 +0800, jackie.huang at windriver.com wrote:
> >> From: Jackie Huang <jackie.huang at windriver.com>
> >>
> >> It's not a good idea to generate the target EFI image in
> >> a native packge,
> >
> > This was admittedly a hack when I wrote it...
> >
> >>   it would be a problem when build a 64bit
> >> target on 32bit host.
> >
> > I build 32b on a 64b host regularly, why is it a problem the other way
> > around?
> >
> > There is infrastructure in place to specify the target architecture for
> > the grub efi binary and the modules. The 32b compiler should be able to
> > do -m64 just as the 64b compiler can do -m32.
> 
> It should be, but for most 32bit linux distributions, gcc is not 
> compiled for supporting 64bit cross compiling.

Thanks for the detail - including this information in the justification
would be a good idea so anyone looking at the commit log can understand
why it was necessary.


> >> -do_install[noexec] = "1"
> >> -do_populate_sysroot[noexec] = "1"
> >> +FILES_${PN}-dbg += "${libdir}/${BPN}/${GRUB_TARGET}-efi/.debug"
> >
> > Technically this is an independent functional change...
> 
> You mean it should be in a separate commit?

I was thinking so, but I see Saul raised it as an issue with V2, so
please disregard this comment, it's fine.

I'd like to see a blurb added to the commit message stating the bit
about gcc not having support in some distributions (debian/ubuntu do
have it for example, but later versions require the compat package or
some such). The fact that some don't is enough though, and your solution
is cleaner and more consistent with bitbake recipe conventions anyway.

Thanks for keeping at it, this is a good improvement.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel