Patchwork xkeyboard-config: this is architecture-indepedent, so set PACKAGE_ARCH

login
register
mail settings
Submitter Ross Burton
Date Feb. 26, 2013, 12:36 p.m.
Message ID <1361882216-8152-1-git-send-email-ross.burton@intel.com>
Download mbox | patch
Permalink /patch/45119/
State New
Headers show

Comments

Ross Burton - Feb. 26, 2013, 12:36 p.m.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb |    2 ++
 1 file changed, 2 insertions(+)
Otavio Salvador - Feb. 26, 2013, 2:32 p.m.
On Tue, Feb 26, 2013 at 9:36 AM, Ross Burton <ross.burton@intel.com> wrote:
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> index 8ca2f6a..ee3e20c 100644
> --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> @@ -19,6 +19,8 @@ SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b
>  SECTION = "x11/libs"
>  DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext"
>
> +PACKAGE_ARCH = "all"
> +
>  PR = "r0"
>
>  EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps"

Please inherit allarch
Ross Burton - Feb. 26, 2013, 5:42 p.m.
On 26 February 2013 14:32, Otavio Salvador <otavio@ossystems.com.br> wrote:
> Please inherit allarch

That doesn't play nicely with autotools:

| checking build system type... x86_64-pc-linux-gnu
| checking host system type... Invalid configuration
`allarch-poky-linux': machine `allarch-poky' not recognized
| configure: error: /bin/bash ./config.sub allarch-poky-linux failed

Considering a lot of allarch is designed to remove dependencies that
this package uses and thus will need to be restored, directly setting
PACKAGE_ARCH is the cleaner solution.

Ross
Otavio Salvador - Feb. 26, 2013, 5:47 p.m.
On Tue, Feb 26, 2013 at 2:42 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 26 February 2013 14:32, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> Please inherit allarch
>
> That doesn't play nicely with autotools:
>
> | checking build system type... x86_64-pc-linux-gnu
> | checking host system type... Invalid configuration
> `allarch-poky-linux': machine `allarch-poky' not recognized
> | configure: error: /bin/bash ./config.sub allarch-poky-linux failed
>
> Considering a lot of allarch is designed to remove dependencies that
> this package uses and thus will need to be restored, directly setting
> PACKAGE_ARCH is the cleaner solution.

If it changes the build depending in target and host, in the end it is
not architecture independant code.
Ross Burton - Feb. 26, 2013, 5:55 p.m.
On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote:
> If it changes the build depending in target and host, in the end it is
> not architecture independant code.

I think this is just autotools being nosy and failing when it doesn't
know what "alllinux" is.  The files don't change as they are literally
just installed.

Ross
Otavio Salvador - Feb. 26, 2013, 6:09 p.m.
On Tue, Feb 26, 2013 at 2:55 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> If it changes the build depending in target and host, in the end it is
>> not architecture independant code.
>
> I think this is just autotools being nosy and failing when it doesn't
> know what "alllinux" is.  The files don't change as they are literally
> just installed.

allarch does more than PACKAGE_ARCH so I think it'd be good to use it.
Maybe it'd not be hard to disable this call in configure.ac? I don't
have a strong opinion about it but using PACKAGE_ARCH only seems like
a workaround for me.
Richard Purdie - Feb. 26, 2013, 7:43 p.m.
On Tue, 2013-02-26 at 17:55 +0000, Burton, Ross wrote:
> On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > If it changes the build depending in target and host, in the end it is
> > not architecture independant code.
> 
> I think this is just autotools being nosy and failing when it doesn't
> know what "alllinux" is.  The files don't change as they are literally
> just installed.

Check exactly what is in configure.ac. You should be able to use allarch
and if you can't, it means the configure script is referencing the
compiler, even if it shouldn't be using it. Its designed such that these
accesses fail verbosely. It should be a simple fix if the recipe really
is just configuration.

Using the allarch class is infinitely preferable as it gets the sstate
bits right.

Cheers,

Richard
Ross Burton - Feb. 26, 2013, 8:44 p.m.
On 26 February 2013 19:43, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Check exactly what is in configure.ac. You should be able to use allarch
> and if you can't, it means the configure script is referencing the
> compiler, even if it shouldn't be using it. Its designed such that these
> accesses fail verbosely. It should be a simple fix if the recipe really
> is just configuration.

| configure:2707: checking host system type
| configure:2716: error: /bin/bash ./config.sub allarch-poky-linux failed

The configure.ac ends up running AC_CANONICAL_HOST because it uses
different manpage sections for Solaris and everything else.

I think they should be using AC_CANONICAL_SYSTEM, but that calls
AC_CANONICAL_HOST anyway so that wouldn't achieve anything.

So, extend my patch, or intrusively patch out the documentation build
code in xkeyboard-config.

Ross
Otavio Salvador - Feb. 26, 2013, 8:52 p.m.
On Tue, Feb 26, 2013 at 5:44 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 26 February 2013 19:43, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> Check exactly what is in configure.ac. You should be able to use allarch
>> and if you can't, it means the configure script is referencing the
>> compiler, even if it shouldn't be using it. Its designed such that these
>> accesses fail verbosely. It should be a simple fix if the recipe really
>> is just configuration.
>
> | configure:2707: checking host system type
> | configure:2716: error: /bin/bash ./config.sub allarch-poky-linux failed
>
> The configure.ac ends up running AC_CANONICAL_HOST because it uses
> different manpage sections for Solaris and everything else.
>
> I think they should be using AC_CANONICAL_SYSTEM, but that calls
> AC_CANONICAL_HOST anyway so that wouldn't achieve anything.
>
> So, extend my patch, or intrusively patch out the documentation build
> code in xkeyboard-config.

I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a
fixed value.
Martin Jansa - Feb. 26, 2013, 10:37 p.m.
On Tue, Feb 26, 2013 at 12:36:56PM +0000, Ross Burton wrote:
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> index 8ca2f6a..ee3e20c 100644
> --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
> @@ -19,6 +19,8 @@ SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b
>  SECTION = "x11/libs"
>  DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext"
>  
> +PACKAGE_ARCH = "all"

Why not inherit allarch?

> +
>  PR = "r0"
>  
>  EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps"
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - Feb. 27, 2013, 2:47 p.m.
On 26 February 2013 20:52, Otavio Salvador <otavio@ossystems.com.br> wrote:
> I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a
> fixed value.

Did that in xorg-macros as that's where the definition is, but
intltool's configure fragment links a program to set DATADIRNAME
(although that appears to be deprecated), so it's trying to find a C
compiler now.

How do I *properly* set allarch so sstate "works" but still allow a
compiler to run so it can identify distribution-specific values (that
have nothing to do with the architecture)?

Ross
Richard Purdie - March 1, 2013, 12:10 a.m.
On Wed, 2013-02-27 at 14:47 +0000, Burton, Ross wrote:
> On 26 February 2013 20:52, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a
> > fixed value.
> 
> Did that in xorg-macros as that's where the definition is, but
> intltool's configure fragment links a program to set DATADIRNAME
> (although that appears to be deprecated), so it's trying to find a C
> compiler now.
> 
> How do I *properly* set allarch so sstate "works" but still allow a
> compiler to run so it can identify distribution-specific values (that
> have nothing to do with the architecture)?

Inherit the class, then set the compiler options to point to the native
compiler? I'm very nervous about doing that mind and would prefer to
"fix" the macros if we can.

Cheers,

Richard

Patch

diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
index 8ca2f6a..ee3e20c 100644
--- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
+++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb
@@ -19,6 +19,8 @@  SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b
 SECTION = "x11/libs"
 DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext"
 
+PACKAGE_ARCH = "all"
+
 PR = "r0"
 
 EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps"