MULTIMACHINE builds and PACKAGE_ARCH=all recipes

MULTIMACHINE builds and PACKAGE_ARCH=all recipes

[Robert Schuster]

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

Hi,
I am in the process of updating the java recipes to use
BBCLASSEXTEND="native" and fixing the do_stage use. However now I hit a
problem because of a workaround which was added months ago to install
Java libraries (jars) into one common directory in a multimachine build.
This workaround was *additionally* specifically added to the angstrom
2008 distribution.

The problem that people wanted to solve was that in a multimachine build
the installation of a PACKAGE_ARCH="all" recipe was only being done once
and so from the 2nd machine onwards the build process was unable to
access the jars.

For me I always wondered how it is for python, C# or perl
programs/libraries which we provide and why there is no problem with
them. As it looks they go the simple way and simply do not appear to
have set PACKAGE_ARCH="all".

So for now I see 2 solutions for the Java recipes:
1) Java packages do not appear as arch-independent anymore.
2) Bitbake (or OE) should be taught to install an arch dependent package
into all sysroots of a multimachine build.

The former is quickly done because most recipes use java-library.bbclass
but I find this technically wrong somehow (it also slows down everyone's
multimachine builds considerably).

I don't know how difficult or feasible it is to implement the 2nd option
(Bitbake gods anyone?) or whether there might even be a third option.

I only know that the shit has hit the fan ... :-/

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: MULTIMACHINE builds and PACKAGE_ARCH=all recipes

[Khem Raj]

On Wed, Aug 4, 2010 at 9:09 AM, Robert Schuster <thebohemian@gmx.net> wrote:
> Hi,
> I am in the process of updating the java recipes to use
> BBCLASSEXTEND="native" and fixing the do_stage use. However now I hit a
> problem because of a workaround which was added months ago to install
> Java libraries (jars) into one common directory in a multimachine build.
> This workaround was *additionally* specifically added to the angstrom
> 2008 distribution.
>
> The problem that people wanted to solve was that in a multimachine build
> the installation of a PACKAGE_ARCH="all" recipe was only being done once

that seems a bug to me.

> and so from the 2nd machine onwards the build process was unable to
> access the jars.
>
> For me I always wondered how it is for python, C# or perl
> programs/libraries which we provide and why there is no problem with
> them. As it looks they go the simple way and simply do not appear to
> have set PACKAGE_ARCH="all".
>
> So for now I see 2 solutions for the Java recipes:
> 1) Java packages do not appear as arch-independent anymore.

its going to work but has additional penalty of compiling stuff.

> 2) Bitbake (or OE) should be taught to install an arch dependent package
> into all sysroots of a multimachine build.
>

this seems the right fix.

> The former is quickly done because most recipes use java-library.bbclass
> but I find this technically wrong somehow (it also slows down everyone's
> multimachine builds considerably).
>
> I don't know how difficult or feasible it is to implement the 2nd option
> (Bitbake gods anyone?) or whether there might even be a third option.
>
> I only know that the shit has hit the fan ... :-/
>
> Regards
> Robert
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>