Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS
Date: Mon, 12 Jul 2010 08:24:29 +0200	[thread overview]
Message-ID: <AANLkTimXB5CusyFxI_DF8g51O2wQed1i-RljaGY2OCOy@mail.gmail.com> (raw)
In-Reply-To: <1278850318.2345.1909.camel@mill.internal.reciva.com>

2010/7/11 Phil Blundell <philb@gnu.org>:
> On Sat, 2010-07-10 at 18:19 +0200, Frans Meulenbroeks wrote:
>> This patch introduces COMPATIBLE_TARGET_SYS
>> It is similar to COMPATIBLE_MACHINE but where COMPATIBLE_MACHINE
>> is used to specify that a certain recipe is for a certain machine
>> COMPATIBLE_TARGET_SYS can be used to specify that a certain recipe
>> is for a certain architecture.
>>
>> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
>
> Per our IRC discussion, I am still not totally comfortable with
> introducing this extra overhead to all users of base.bbclass.  In the
> vast majority of cases (i.e. essentially all packages apart from
> toolchain ones), TARGET_SYS == HOST_SYS and hence checking both of them
> is just a waste of time.  But I do take your point about wanting to mop
> up both cross and regular gcc.

Wrt the additional overhead. That is indeed a pity. Then again the
overhead is not that big (but ofc every penny counts).

A possible solution would be to rewrite the complete way variables are
stored and compared.
E.g. if the constraints would be hashed adding an additional variable
and constraint would simply be an extension to the hash table
(and not take up cpu cycles expect if there is hash clash).

But imho this is not something done overnight.

BTW: there are other ways to reduce parsing time, but people do not
like it if I mention them :-)
>
> I think I would prefer to see the TARGET_SYS check placed in some common
> place which can be included by all toolchain recipes (and, possibly, a
> general ongoing effort to reduce the number of non-cross recipes which
> refer explicitly to TARGET_xx when HOST_xx would do).  But I don't have
> a very strong view on the matter and, if there is a general consensus in
> favour of putting this in base.bbclass, I will go along with that.

Thanks.

Any other opinions? Acks ?

BTW: i did a quick peek at the cross stuff that we have: currently
there are four recipes that have a cross variant:
gcc, binutils, gdb and libtool.
For nios2 I didn't even have a look at the last two.

Have fun! Frans



  reply	other threads:[~2010-07-12  6:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 18:38 [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE Frans Meulenbroeks
2010-07-07 18:49 ` Frans Meulenbroeks
2010-07-07 18:57   ` Phil Blundell
2010-07-07 19:11     ` Frans Meulenbroeks
2010-07-07 19:44       ` Phil Blundell
2010-07-08  6:49         ` Frans Meulenbroeks
2010-07-08  8:23           ` Phil Blundell
2010-07-10 16:19             ` [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS Frans Meulenbroeks
2010-07-10 17:42               ` Tom Rini
2010-07-10 22:36               ` Phil Blundell
2010-07-11  6:55                 ` Frans Meulenbroeks
2010-07-11  7:16                   ` Frans Meulenbroeks
2010-07-11  7:48                     ` [PATCH v2] base.bbclass: introduce COMPATIBLE_TARGET_SYS and COMPATIBLE_TARGET_ARCH Frans Meulenbroeks
2010-07-11  9:10                       ` Phil Blundell
2010-07-11 12:11               ` [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS Phil Blundell
2010-07-12  6:24                 ` Frans Meulenbroeks [this message]
2010-07-14  7:27                   ` Esben Haabendal
2010-07-10 16:23             ` [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE Frans Meulenbroeks
2010-07-10 22:52               ` Khem Raj
2010-07-08 17:07     ` Denys Dmytriyenko

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=AANLkTimXB5CusyFxI_DF8g51O2wQed1i-RljaGY2OCOy@mail.gmail.com \
    --to=fransmeulenbroeks@gmail.com \
    --cc=openembedded-devel@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox