All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/7] allarch: Always inhibit default dependencies and set empty TARGET_PREFIX
Date: Mon, 18 Nov 2013 16:58:24 +0100	[thread overview]
Message-ID: <20131118155824.GF3727@jama> (raw)
In-Reply-To: <20131118155442.GE3727@jama>

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

      reply	other threads:[~2013-11-18 15:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 12:12 [RFC][PATCH] packagegroup.bbclass: Drop build-time dependencies Martin Jansa
2013-11-01 13:37 ` Paul Eggleton
2013-11-01 18:14   ` Richard Purdie
2013-11-01 19:06     ` Paul Eggleton
2013-11-17 13:52 ` [PATCH 1/7] allarch: Always inhibit default dependencies and set empty TARGET_PREFIX Martin Jansa
2013-11-17 13:52   ` [PATCH 2/7] packagegroup-core-boot: Drop build-time dependency on virtual/kernel Martin Jansa
2013-11-20  5:57     ` ChenQi
2013-11-17 13:52   ` [PATCH 3/7] xuser-account: Drop allarch inherit Martin Jansa
2013-11-17 13:52   ` [PATCH 4/7] linux-firmware: Drop allarch Martin Jansa
2013-11-18 10:57     ` Richard Purdie
2013-11-17 13:52   ` [PATCH 5/7] ppp-dialin: " Martin Jansa
2013-11-17 13:52   ` [PATCH 6/7] initramfs-framework: " Martin Jansa
2013-11-17 13:52   ` [PATCH 7/7] resolvconf: " Martin Jansa
2013-11-18 12:31   ` [PATCH 1/7] allarch: Always inhibit default dependencies and set empty TARGET_PREFIX Richard Purdie
2013-11-18 15:54     ` Martin Jansa
2013-11-18 15:58       ` Martin Jansa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131118155824.GF3727@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.