Patchwork [1/7] allarch: Always inhibit default dependencies and set empty TARGET_PREFIX

login
register
mail settings
Submitter Martin Jansa
Date Nov. 17, 2013, 1:52 p.m.
Message ID <1384696338-5390-1-git-send-email-Martin.Jansa@gmail.com>
Download mbox | patch
Permalink /patch/61873/
State New
Headers show

Comments

Martin Jansa - Nov. 17, 2013, 1:52 p.m.
* typical case where we inherit allarch and override PACKAGE_ARCH
  are packagegroup recipes, but those need default dependencies
  inhibited even when they are MACHINE_ARCH or TUNE_PKGARCH.
  I don't know about any recipe which inherits allarch and needs
  default dependencies.
* set empty TARGET_PREFIX
  This has a bit weird reason caused by unsupported setup where
  external-toolchain is used in some DISTRO only for some MACHINEs
  and internal is used for other MACHINEs.
  Because external-toolchain usually comes with different TARGET_PREFIX
  it was causing allarch recipes to have different signatures even
  when they don't use toolchain at all.
  Empty TARGET_PREFIX also helps to find allarch recipes which still
  have default dependency on e.g. virtual/${TARGET_PREFIX}gcc.

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/classes/allarch.bbclass | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
Richard Purdie - Nov. 18, 2013, 12:31 p.m.
On Sun, 2013-11-17 at 14:52 +0100, Martin Jansa wrote:
> * typical case where we inherit allarch and override PACKAGE_ARCH
>   are packagegroup recipes, but those need default dependencies
>   inhibited even when they are MACHINE_ARCH or TUNE_PKGARCH.
>   I don't know about any recipe which inherits allarch and needs
>   default dependencies.

The code there was added to allow the allarch class to be enabled or
disabled. I don't remember exactly why we needed to do that however it
was added for a reason and making part of it unconditional again will
probably break whyever we made it optional :(.

I can understand how you came to this conclusion though. Which cases is
this causing problems for?

> * set empty TARGET_PREFIX
>   This has a bit weird reason caused by unsupported setup where
>   external-toolchain is used in some DISTRO only for some MACHINEs
>   and internal is used for other MACHINEs.
>   Because external-toolchain usually comes with different TARGET_PREFIX
>   it was causing allarch recipes to have different signatures even
>   when they don't use toolchain at all.
>   Empty TARGET_PREFIX also helps to find allarch recipes which still
>   have default dependency on e.g. virtual/${TARGET_PREFIX}gcc.

This seems ok, I'd have taken it if it was a separate patch.

Cheers,

Richard
Martin Jansa - Nov. 18, 2013, 3:54 p.m.
On Mon, Nov 18, 2013 at 12:31:15PM +0000, Richard Purdie wrote:
> On Sun, 2013-11-17 at 14:52 +0100, Martin Jansa wrote:
> > * typical case where we inherit allarch and override PACKAGE_ARCH
> >   are packagegroup recipes, but those need default dependencies
> >   inhibited even when they are MACHINE_ARCH or TUNE_PKGARCH.
> >   I don't know about any recipe which inherits allarch and needs
> >   default dependencies.
> 
> The code there was added to allow the allarch class to be enabled or
> disabled. I don't remember exactly why we needed to do that however it
> was added for a reason and making part of it unconditional again will
> probably break whyever we made it optional :(.

I think that use case was MACHINE_ARCH packagegroups loosing -gnueabi
suffix, so that everything except packagegroups (or other MACHINE_ARCH
allarch recipes) was built in workdir:
MACHINE-oe-linux-gnueabi
and packagegroups in
MACHINE-oe-linux

I don't think we had the use case where we needed to conditionally keep
default deps (but of course my memory isn't perfect and I can be wrong).
 
> I can understand how you came to this conclusion though. Which cases is
> this causing problems for?
> 
> > * set empty TARGET_PREFIX
> >   This has a bit weird reason caused by unsupported setup where
> >   external-toolchain is used in some DISTRO only for some MACHINEs
> >   and internal is used for other MACHINEs.
> >   Because external-toolchain usually comes with different TARGET_PREFIX
> >   it was causing allarch recipes to have different signatures even
> >   when they don't use toolchain at all.
> >   Empty TARGET_PREFIX also helps to find allarch recipes which still
> >   have default dependency on e.g. virtual/${TARGET_PREFIX}gcc.
> 
> This seems ok, I'd have taken it if it was a separate patch.

It's related to above, because "thanks" to empty TARGET_PREFIX I've
found few MACHINE_ARCH+allarch recipes in meta-webos which weren't using
toolchain, but default deps had nonexistent "virtual/gcc".

So we cannot merge TARGET_PREFIX without the above part.
Martin Jansa - Nov. 18, 2013, 3:58 p.m.
On Mon, Nov 18, 2013 at 04:54:42PM +0100, Martin Jansa wrote:
> On Mon, Nov 18, 2013 at 12:31:15PM +0000, Richard Purdie wrote:
> > On Sun, 2013-11-17 at 14:52 +0100, Martin Jansa wrote:
> > > * typical case where we inherit allarch and override PACKAGE_ARCH
> > >   are packagegroup recipes, but those need default dependencies
> > >   inhibited even when they are MACHINE_ARCH or TUNE_PKGARCH.
> > >   I don't know about any recipe which inherits allarch and needs
> > >   default dependencies.
> > 
> > The code there was added to allow the allarch class to be enabled or
> > disabled. I don't remember exactly why we needed to do that however it
> > was added for a reason and making part of it unconditional again will
> > probably break whyever we made it optional :(.
> 
> I think that use case was MACHINE_ARCH packagegroups loosing -gnueabi
> suffix, so that everything except packagegroups (or other MACHINE_ARCH
> allarch recipes) was built in workdir:
> MACHINE-oe-linux-gnueabi
> and packagegroups in
> MACHINE-oe-linux
> 
> I don't think we had the use case where we needed to conditionally keep
> default deps (but of course my memory isn't perfect and I can be wrong).
>  
> > I can understand how you came to this conclusion though. Which cases is
> > this causing problems for?
> > 
> > > * set empty TARGET_PREFIX
> > >   This has a bit weird reason caused by unsupported setup where
> > >   external-toolchain is used in some DISTRO only for some MACHINEs
> > >   and internal is used for other MACHINEs.
> > >   Because external-toolchain usually comes with different TARGET_PREFIX
> > >   it was causing allarch recipes to have different signatures even
> > >   when they don't use toolchain at all.
> > >   Empty TARGET_PREFIX also helps to find allarch recipes which still
> > >   have default dependency on e.g. virtual/${TARGET_PREFIX}gcc.
> > 
> > This seems ok, I'd have taken it if it was a separate patch.
> 
> It's related to above, because "thanks" to empty TARGET_PREFIX I've
> found few MACHINE_ARCH+allarch recipes in meta-webos which weren't using
> toolchain, but default deps had nonexistent "virtual/gcc".

Ah sorry this wasn't very accurate, I've found it with earlier version
of this patch which was unconditionally inhibiting default deps only for
packagegroup.bbclass not allarch.bbclass where it should be.

Patch

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 5e13a5b..4a65f77 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -9,12 +9,13 @@  STAGING_DIR_HOST := "${STAGING_DIR_HOST}"
 PACKAGE_ARCH = "all"
 
 python () {
+    # No need for virtual/libc or a cross compiler even for recipes which
+    # change PACKAGE_ARCH e.g. to MACHINE_ARCH
+    d.setVar("INHIBIT_DEFAULT_DEPS","1")
+
     # Allow this class to be included but overridden - only set
     # the values if we're still "all" package arch.
     if d.getVar("PACKAGE_ARCH") == "all":
-        # No need for virtual/libc or a cross compiler
-        d.setVar("INHIBIT_DEFAULT_DEPS","1")
-
         # Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
         # naming anyway
         d.setVar("TARGET_ARCH", "allarch")
@@ -23,6 +24,7 @@  python () {
         d.setVar("TARGET_LD_ARCH", "none")
         d.setVar("TARGET_AS_ARCH", "none")
         d.setVar("PACKAGE_EXTRA_ARCHS", "")
+        d.setVar("TARGET_PREFIX", "")
 
         # No need to do shared library processing or debug symbol handling
         d.setVar("EXCLUDE_FROM_SHLIBS", "1")