[PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Frans Meulenbroeks]

added INCOMPATIBLE_MACHINE
we have COMPATIBLE_MACHINE but that does not allow to say that
a package is supported by all except a certain machine.
a regexp like "(?!arch)"
This mechanism can be used to exclude certain machines.
Idea is that in binutils and gcc you can use this to specify that
a certain version does not support a certain machine

Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
---
 classes/base.bbclass |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/classes/base.bbclass b/classes/base.bbclass
index 2da0b7a..3174469 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -380,6 +380,13 @@ python () {
             if this_machine and not re.match(need_machine, this_machine):
                 raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
 
+        need_machine = bb.data.getVar('INCOMPATIBLE_MACHINE', d, 1)
+        if need_machine:
+            import re
+            this_machine = bb.data.getVar('MACHINE', d, 1)
+            if this_machine and re.match(need_machine, this_machine):
+                raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
+
     pn = bb.data.getVar('PN', d, 1)
 
     # OBSOLETE in bitbake 1.7.4
-- 
1.6.4.2

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Frans Meulenbroeks]

2010/7/7 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> added INCOMPATIBLE_MACHINE
> we have COMPATIBLE_MACHINE but that does not allow to say that
> a package is supported by all except a certain machine.
> a regexp like "(?!arch)"
> This mechanism can be used to exclude certain machines.
> Idea is that in binutils and gcc you can use this to specify that
> a certain version does not support a certain machine

actually what I wanted to say in the commit message is that a regexp
like (?!arch) does not work.
\b(?!arch) or ^(?!arch) didn't work either and consulting #python did
also not give a solution to
exclude a string.

If I get enough acks for this I will commit after improving the commit message
>
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
>  classes/base.bbclass |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/classes/base.bbclass b/classes/base.bbclass
> index 2da0b7a..3174469 100644
> --- a/classes/base.bbclass
> +++ b/classes/base.bbclass
> @@ -380,6 +380,13 @@ python () {
>             if this_machine and not re.match(need_machine, this_machine):
>                 raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
>
> +        need_machine = bb.data.getVar('INCOMPATIBLE_MACHINE', d, 1)
> +        if need_machine:
> +            import re
> +            this_machine = bb.data.getVar('MACHINE', d, 1)
> +            if this_machine and re.match(need_machine, this_machine):
> +                raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
> +
>     pn = bb.data.getVar('PN', d, 1)
>
>     # OBSOLETE in bitbake 1.7.4
> --
> 1.6.4.2
>
>

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Phil Blundell]

On Wed, 2010-07-07 at 20:49 +0200, Frans Meulenbroeks wrote:
> 2010/7/7 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> > added INCOMPATIBLE_MACHINE
> > we have COMPATIBLE_MACHINE but that does not allow to say that
> > a package is supported by all except a certain machine.
> > a regexp like "(?!arch)"
> > This mechanism can be used to exclude certain machines.
> > Idea is that in binutils and gcc you can use this to specify that
> > a certain version does not support a certain machine
> 
> actually what I wanted to say in the commit message is that a regexp
> like (?!arch) does not work.
> \b(?!arch) or ^(?!arch) didn't work either and consulting #python did

This might just be an accident of wording, but you do realise that
COMPATIBLE_MACHINE is tested against ${MACHINE} (i.e. not any of the
${xx_ARCH} variables), right?  If you want to test arches then you want
${COMPATIBLE_ARCH}.

I just did a quick test with (?!foo) in C_M and it seemed to work ok for
me.  Specifically:

MACHINE = goodmach
COMPATIBLE_MACHINE = "(?!badmach)"

works, whereas

MACHINE = badmach
COMPATIBLE_MACHINE = "(?!badmach)"

is rejected.  What exactly goes wrong for you?

p.

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Frans Meulenbroeks]

2010/7/7 Phil Blundell <philb@gnu.org>:
> On Wed, 2010-07-07 at 20:49 +0200, Frans Meulenbroeks wrote:
>> 2010/7/7 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>> > added INCOMPATIBLE_MACHINE
>> > we have COMPATIBLE_MACHINE but that does not allow to say that
>> > a package is supported by all except a certain machine.
>> > a regexp like "(?!arch)"
>> > This mechanism can be used to exclude certain machines.
>> > Idea is that in binutils and gcc you can use this to specify that
>> > a certain version does not support a certain machine
>>
>> actually what I wanted to say in the commit message is that a regexp
>> like (?!arch) does not work.
>> \b(?!arch) or ^(?!arch) didn't work either and consulting #python did
>
> This might just be an accident of wording, but you do realise that
> COMPATIBLE_MACHINE is tested against ${MACHINE} (i.e. not any of the
> ${xx_ARCH} variables), right?  If you want to test arches then you want
> ${COMPATIBLE_ARCH}.
>
> I just did a quick test with (?!foo) in C_M and it seemed to work ok for
> me.  Specifically:
>
> MACHINE = goodmach
> COMPATIBLE_MACHINE = "(?!badmach)"
>
> works, whereas
>
> MACHINE = badmach
> COMPATIBLE_MACHINE = "(?!badmach)"
>
> is rejected.  What exactly goes wrong for you?

Aargh, yes I was using COMPATIBLE_MACHINE to test against an arch.

COMPATIBLE_ARCH does not exist at the moment.
Is there interest in it? (or in other words, do I have a chance I get
acks for it, if not I'd rather save myself the effort writing a patch

Frans

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Phil Blundell]

On Wed, 2010-07-07 at 21:11 +0200, Frans Meulenbroeks wrote:
> COMPATIBLE_ARCH does not exist at the moment.
> Is there interest in it? (or in other words, do I have a chance I get
> acks for it, if not I'd rather save myself the effort writing a patch

Sorry, you're right, I had remembered it wrong.  It's ${COMPATIBLE_HOST}
that I was thinking of, and I guess that doesn't do what you need in the
specific case of cross packages.

I guess I would be happy enough to see support for ${COMPATIBLE_TARGET}
added to cross.bbclass if such a thing doesn't already exist.

p.

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Frans Meulenbroeks]

2010/7/7 Phil Blundell <philb@gnu.org>:
> On Wed, 2010-07-07 at 21:11 +0200, Frans Meulenbroeks wrote:
>> COMPATIBLE_ARCH does not exist at the moment.
>> Is there interest in it? (or in other words, do I have a chance I get
>> acks for it, if not I'd rather save myself the effort writing a patch
>
> Sorry, you're right, I had remembered it wrong.  It's ${COMPATIBLE_HOST}
> that I was thinking of, and I guess that doesn't do what you need in the
> specific case of cross packages.
>
> I guess I would be happy enough to see support for ${COMPATIBLE_TARGET}
> added to cross.bbclass if such a thing doesn't already exist.

I feel this is a good plan. Are there other supporters for this as
well (before I start working on it)?

The only concern I have is the name COMPATIBLE_TARGET
for me TARGET is the board so COMPATIBLE_TARGET for me more or less
equates to COMPATIBLE_MACHINE.
What about COMPATIBLE_ARCH or COMPATIBLE_ARCHITECTURE?

Frans

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Phil Blundell]

On Thu, 2010-07-08 at 08:49 +0200, Frans Meulenbroeks wrote: 
> The only concern I have is the name COMPATIBLE_TARGET
> for me TARGET is the board so COMPATIBLE_TARGET for me more or less
> equates to COMPATIBLE_MACHINE.
> What about COMPATIBLE_ARCH or COMPATIBLE_ARCHITECTURE?

I think the variable that you want to match against (in the specific
case of cross.bbclass) is ${TARGET_SYS}.  Having the matching variable
be named COMPATIBLE_ARCH would imply that it's going to match
${HOST_ARCH}, which obviously isn't what you want.

I would have thought that confusion with ${MACHINE} should be minimal
since that nomenclature is already quite well established in OE.  But
you could name it COMPATIBLE_TARGET_SYS if you wanted to make the name
completely explicit.

p.

[PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Frans Meulenbroeks]

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>

---

as also discussed on the oe ML in the thread
[PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE
---
 classes/base.bbclass |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/classes/base.bbclass b/classes/base.bbclass
index b30310d..f76d03c 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -391,6 +391,13 @@ python () {
             if this_machine and not re.match(need_machine, this_machine):
                 raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
 
+        need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
+        if need_target:
+            import re
+            this_target = bb.data.getVar('TARGET_SYS', d, 1)
+            if this_target and not re.match(need_target, this_target):
+                raise bb.parse.SkipPackage("incompatible with target system %s" % this_target)
+
     pn = bb.data.getVar('PN', d, 1)
 
     # OBSOLETE in bitbake 1.7.4
-- 
1.6.4.2

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Tom Rini]

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>

Acked-by: Tom Rini <tom_rini@mentor.com>

> 
> ---
> 
> as also discussed on the oe ML in the thread
> [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE
> ---
>  classes/base.bbclass |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/classes/base.bbclass b/classes/base.bbclass
> index b30310d..f76d03c 100644
> --- a/classes/base.bbclass
> +++ b/classes/base.bbclass
> @@ -391,6 +391,13 @@ python () {
>              if this_machine and not re.match(need_machine, this_machine):
>                  raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
>  
> +        need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
> +        if need_target:
> +            import re
> +            this_target = bb.data.getVar('TARGET_SYS', d, 1)
> +            if this_target and not re.match(need_target, this_target):
> +                raise bb.parse.SkipPackage("incompatible with target system %s" % this_target)
> +
>      pn = bb.data.getVar('PN', d, 1)
>  
>      # OBSOLETE in bitbake 1.7.4


-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Phil Blundell]

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>

I think this should go in cross.bbclass, not base.bbclass.  Other than
that it looks fine.

p.

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Frans Meulenbroeks]

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>
>
> I think this should go in cross.bbclass, not base.bbclass.  Other than
> that it looks fine.
>

I have no real preference for location. The only reason for putting it
in base.bbclass is because that file also contains the tests for
COMPATIBLE_MACHINE and COMPATIBLE_HOST.
(as my pythonese is not that good I just copied/pasted/edited/tested there)
Please advice

Wrt the clarification of khem in the other thread:
What about adding a COMPATIBLE_TARGET_ARCH test  too ? (actually I
think that that is the one I would like to use at one place (although
ofc it is quite possible to use COMPATIBLE_TARGET_SYS).
(e.g. gblic has arch specific sysdeps, I would like to specify if a
version of glibc does not specify my arch).

Frans

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Frans Meulenbroeks]

2010/7/11 Frans Meulenbroeks <fransmeulenbroeks@gmail.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>
>>
>> I think this should go in cross.bbclass, not base.bbclass.  Other than
>> that it looks fine.
>>
>
> I have no real preference for location. The only reason for putting it
> in base.bbclass is because that file also contains the tests for
> COMPATIBLE_MACHINE and COMPATIBLE_HOST.
> (as my pythonese is not that good I just copied/pasted/edited/tested there)
> Please advice

Thinking about it again, base.bbclass seems a better place to me.
This test could also apply at compiling non-cross stuff (e.g. if a
recipe contains inline asm that is not ported)
and of course for recipes like gcc, if the arch or sys is not
supported, it'll be for cross and target.
I'm not too good at the build system internals, but I expect that gcc
(not gcc-cross) does not use cross.bbclass. (and I guess we want to
say for gcc too that it is not compatible)
So I feel base.bbclass look like a better place.

Frans.
>
> Wrt the clarification of khem in the other thread:
> What about adding a COMPATIBLE_TARGET_ARCH test  too ? (actually I
> think that that is the one I would like to use at one place (although
> ofc it is quite possible to use COMPATIBLE_TARGET_SYS).
> (e.g. gblic has arch specific sysdeps, I would like to specify if a
> version of glibc does not specify my arch).
>
> Frans
>

[PATCH v2] base.bbclass: introduce COMPATIBLE_TARGET_SYS and COMPATIBLE_TARGET_ARCH

[Frans Meulenbroeks]

This patch introduces COMPATIBLE_TARGET_SYS and COMPATIBLE_TARGET_ARCH
They are 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 target system (e.g. mips-oe-linux),
COMPATIBLE_TARGET_ARCH can be used that a certain recipe is for a certain
architecture (e.g. mips)

Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
---

This patch supersedes [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SY

as restrictions may apply for both native and cross recipes, the patch is in base.bbclass, not cross.bbclass.

Khem, if you agree, can you confirm your ack.
And can I see one more ack for this?

Thanks, Frans.

 classes/base.bbclass |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/classes/base.bbclass b/classes/base.bbclass
index b30310d..4bc7650 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -391,6 +391,20 @@ python () {
             if this_machine and not re.match(need_machine, this_machine):
                 raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
 
+        need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
+        if need_target:
+            import re
+            this_target = bb.data.getVar('TARGET_SYS', d, 1)
+            if this_target and not re.match(need_target, this_target):
+                raise bb.parse.SkipPackage("incompatible with target system %s" % this_target)
+
+        need_arch = bb.data.getVar('COMPATIBLE_TARGET_ARCH', d, 1)
+        if need_arch:
+            import re
+            this_arch = bb.data.getVar('TARGET_ARCH', d, 1)
+            if this_arch and not re.match(need_arch, this_arch):
+                raise bb.parse.SkipPackage("incompatible with architecture %s" % this_arch)
+
     pn = bb.data.getVar('PN', d, 1)
 
     # OBSOLETE in bitbake 1.7.4
-- 
1.6.4.2

Re: [PATCH v2] base.bbclass: introduce COMPATIBLE_TARGET_SYS and COMPATIBLE_TARGET_ARCH

[Phil Blundell]

On Sun, 2010-07-11 at 09:48 +0200, Frans Meulenbroeks wrote:
> This patch introduces COMPATIBLE_TARGET_SYS and COMPATIBLE_TARGET_ARCH
> They are 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 target system (e.g. mips-oe-linux),
> COMPATIBLE_TARGET_ARCH can be used that a certain recipe is for a certain
> architecture (e.g. mips)

Why do you need both?  Surely COMPATIBLE_TARGET_ARCH can be implemented
by testing against COMPATIBLE_TARGET_SYS with a suitable wildcard.

> as restrictions may apply for both native and cross recipes, the patch
> is in base.bbclass, not cross.bbclass.

TARGET_SYS only has real meaning for cross recipes.  For standard host
recipes, the variable to check would be HOST_SYS (via COMPATIBLE_HOST).
I'm not sure that putting cross-specific stuff in base.bbclass is a
wholesome plan.

p.

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Phil Blundell]

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.

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.

p.

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Frans Meulenbroeks]

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

Re: [PATCH] base.bbclass: introduce COMPATIBLE_TARGET_SYS

[Esben Haabendal]

On Mon, Jul 12, 2010 at 8:24 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> BTW: there are other ways to reduce parsing time, but people do not
> like it if I mention them :-)

I for one, would like if you cared to mention them, please :-)

/Esben

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Frans Meulenbroeks]

2010/7/8 Phil Blundell <philb@gnu.org>:
> On Thu, 2010-07-08 at 08:49 +0200, Frans Meulenbroeks wrote:
>> The only concern I have is the name COMPATIBLE_TARGET
>> for me TARGET is the board so COMPATIBLE_TARGET for me more or less
>> equates to COMPATIBLE_MACHINE.
>> What about COMPATIBLE_ARCH or COMPATIBLE_ARCHITECTURE?
>
> I think the variable that you want to match against (in the specific
> case of cross.bbclass) is ${TARGET_SYS}.  Having the matching variable
> be named COMPATIBLE_ARCH would imply that it's going to match
> ${HOST_ARCH}, which obviously isn't what you want.
>
> I would have thought that confusion with ${MACHINE} should be minimal
> since that nomenclature is already quite well established in OE.  But
> you could name it COMPATIBLE_TARGET_SYS if you wanted to make the name
> completely explicit.
>
Patch posted. I named it COMPATIBLE_TARGET_SYS and compare with TARGET_SYS.
Tested it, and for me it works like a charm.

However just after posting I noticed we also have TARGET_ARCH.
I'm a little bit lost wrt the differences between these.
Let me know if I need to move to *ARCH

Frans

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Khem Raj]

On Sat, Jul 10, 2010 at 9:23 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/7/8 Phil Blundell <philb@gnu.org>:
>> On Thu, 2010-07-08 at 08:49 +0200, Frans Meulenbroeks wrote:
>>> The only concern I have is the name COMPATIBLE_TARGET
>>> for me TARGET is the board so COMPATIBLE_TARGET for me more or less
>>> equates to COMPATIBLE_MACHINE.
>>> What about COMPATIBLE_ARCH or COMPATIBLE_ARCHITECTURE?
>>
>> I think the variable that you want to match against (in the specific
>> case of cross.bbclass) is ${TARGET_SYS}.  Having the matching variable
>> be named COMPATIBLE_ARCH would imply that it's going to match
>> ${HOST_ARCH}, which obviously isn't what you want.
>>
>> I would have thought that confusion with ${MACHINE} should be minimal
>> since that nomenclature is already quite well established in OE.  But
>> you could name it COMPATIBLE_TARGET_SYS if you wanted to make the name
>> completely explicit.
>>
> Patch posted. I named it COMPATIBLE_TARGET_SYS and compare with TARGET_SYS.
> Tested it, and for me it works like a charm.
>
> However just after posting I noticed we also have TARGET_ARCH.
> I'm a little bit lost wrt the differences between these.
> Let me know if I need to move to *ARCH

TARGET_ARCH is the architecture e.g. arm. mips etc.
TARGET_SYS is canonical name like arm-oe-linux-uclibceabi or mips-oe-linux etc.

>
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [PATCH] classes/base.bbclass: add INCOMPATIBLE_MACHINE

[Denys Dmytriyenko]

On Wed, Jul 07, 2010 at 07:57:15PM +0100, Phil Blundell wrote:
> On Wed, 2010-07-07 at 20:49 +0200, Frans Meulenbroeks wrote:
> > 2010/7/7 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> > > added INCOMPATIBLE_MACHINE
> > > we have COMPATIBLE_MACHINE but that does not allow to say that
> > > a package is supported by all except a certain machine.
> > > a regexp like "(?!arch)"
> > > This mechanism can be used to exclude certain machines.
> > > Idea is that in binutils and gcc you can use this to specify that
> > > a certain version does not support a certain machine
> > 
> > actually what I wanted to say in the commit message is that a regexp
> > like (?!arch) does not work.
> > \b(?!arch) or ^(?!arch) didn't work either and consulting #python did
> 
> This might just be an accident of wording, but you do realise that
> COMPATIBLE_MACHINE is tested against ${MACHINE} (i.e. not any of the
> ${xx_ARCH} variables), right?  If you want to test arches then you want
> ${COMPATIBLE_ARCH}.
> 
> I just did a quick test with (?!foo) in C_M and it seemed to work ok for
> me.  Specifically:
> 
> MACHINE = goodmach
> COMPATIBLE_MACHINE = "(?!badmach)"
> 
> works, whereas
> 
> MACHINE = badmach
> COMPATIBLE_MACHINE = "(?!badmach)"
> 
> is rejected.  What exactly goes wrong for you?

Just to confirm that the regular expression above does work, when tested 
against the correct variable, as I've been using it for quite a while in my 
recipes, e.g.:

http://arago-project.org/git/?p=arago.git;a=blob;f=recipes/images/arago-qte-image.bb;hb=HEAD

-- 
Denys