[Buildroot] multiple architectures

[Buildroot] multiple architectures

[Igor Serebryany]

Hi!

	I need both an x86 and an amd64 version of my buildroot filesystem
	and kernel. I've been making this happen by a very inefficient
	process - keeping two copies of the buildroot source (one for each
	arch), making local/projectname an svn working copy, making all
	changes to the x86 version and using 'svn update' to merge changes
	back into the amd64 version.

	I'm sure there must be a better way. How do people on here manage
	maintaining identical builds for multiple architectures? 

--Igor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090930/58eede28/attachment.pgp>

[Buildroot] multiple architectures

[Thomas Petazzoni]

Le Wed, 30 Sep 2009 01:26:58 -0500,
Igor Serebryany <igor47@moomers.org> a ?crit :

> 	I need both an x86 and an amd64 version of my buildroot
> filesystem and kernel. I've been making this happen by a very
> inefficient process - keeping two copies of the buildroot source (one
> for each arch), making local/projectname an svn working copy, making
> all changes to the x86 version and using 'svn update' to merge changes
> 	back into the amd64 version.
> 
> 	I'm sure there must be a better way. How do people on here
> manage maintaining identical builds for multiple architectures? 

Use out-of-tree compilation with O=, with two different configurations
files.

Say ~/buildroot contains your Buildroot source code :

 * Store your x86 configuration in ~/buildroot/config.x86 and your
   x86_64 configuration in ~/buildroot/config.x86_64

 * To run the x86 compilation, do :

    cd ~/buildroot/
    cp config.x86 .config
    make O=~/buildroot-x86

 * To run the x86_64 compilation, do :

    cd ~/buildroot/
    cp config.x86_64 .config
    make O=~/buildroot-x86_64

Of course, when you make a change to one of the .config, make sure that
you update the corresponding config.{x86,x86_64}.

Do that solves your problem ?

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090930/bf48a650/attachment.pgp>

[Buildroot] multiple architectures

[Igor Serebryany]

On Wed, Sep 30, 2009 at 09:01:02AM +0200, Thomas Petazzoni wrote:
> Of course, when you make a change to one of the .config, make sure that
> you update the corresponding config.{x86,x86_64}.

This is the problem that I've been using svn to solve, by 
* running 'make saveconfig', 
* committing the resulting local/myproject directory to a repository
* running 'svn update' in another local/myproject64 directory that
points at the same repository but the working copy has been customized for
64bit architecture. 

svn update then merges the config changes, leaving the local
modifications (especially to the kernel .config) in place.

i was hoping there was some kind of magical make flag that would use the
same config files but do some kind of 'oh edit it for this other
architecture' magic.

--igor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090930/6f0db4ca/attachment.pgp>

[Buildroot] multiple architectures

[Bjørn Forsman]

Hi,

2009/9/30 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Wed, 30 Sep 2009 01:26:58 -0500,
> Igor Serebryany <igor47@moomers.org> a ?crit :
>
>> ? ? ? I need both an x86 and an amd64 version of my buildroot
>> filesystem and kernel. I've been making this happen by a very
>> inefficient process - keeping two copies of the buildroot source (one
>> for each arch), making local/projectname an svn working copy, making
>> all changes to the x86 version and using 'svn update' to merge changes
>> ? ? ? back into the amd64 version.
>>
>> ? ? ? I'm sure there must be a better way. How do people on here
>> manage maintaining identical builds for multiple architectures?
>
> Use out-of-tree compilation with O=, with two different configurations
> files.

How about that the default BR output directory contains an arch
postfix? This would eliminate the need for manually setting O=
according to the current .config. Instead it would happen
automatically.

Any thoughts?

Regards,
Bj?rn Forsman

[Buildroot] multiple architectures

[Thomas Petazzoni]

Le Wed, 30 Sep 2009 10:13:22 +0200,
Bj?rn Forsman <bjorn.forsman@gmail.com> a ?crit :

> How about that the default BR output directory contains an arch
> postfix? This would eliminate the need for manually setting O=
> according to the current .config. Instead it would happen
> automatically.

This was the case previously. But I don't think it's a good idea, since
it only solves partially the problem: what if you have several
projects, but all these projects use the same architecture ?

This is even more common than multiple architectures projects: you work
on ARM (for example), but you build different filesystems for different
usages of the device. In that case, a default output-arm/ directory
would not solve the problem.

A possibility would be to add a configuration option to set the output
directory path, instead of passing O=. I don't have a strong opinion on
this, but I'd prefer not to have both solutions. The fact that
Buildroot has multiple solutions to do approximately the same thing is
a large part of the confusion for our new users, and I would like to
reduce this confusion.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] multiple architectures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> A possibility would be to add a configuration option to set the
 Thomas> output directory path, instead of passing O=. I don't have a
 Thomas> strong opinion on this, but I'd prefer not to have both
 Thomas> solutions. The fact that Buildroot has multiple solutions to do
 Thomas> approximately the same thing is a large part of the confusion
 Thomas> for our new users, and I would like to reduce this confusion.

FYI, I agree with all of the above.

-- 
Bye, Peter Korsgaard

[Buildroot] multiple architectures

[Bjørn Forsman]

Hi,

2009/9/30 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Wed, 30 Sep 2009 10:13:22 +0200,
> Bj?rn Forsman <bjorn.forsman@gmail.com> a ?crit :
>
>> How about that the default BR output directory contains an arch
>> postfix? This would eliminate the need for manually setting O=
>> according to the current .config. Instead it would happen
>> automatically.
>
> This was the case previously. But I don't think it's a good idea, since
> it only solves partially the problem: what if you have several
> projects, but all these projects use the same architecture ?
>
> This is even more common than multiple architectures projects: you work
> on ARM (for example), but you build different filesystems for different
> usages of the device. In that case, a default output-arm/ directory
> would not solve the problem.

Oops, I forgot about multi-arch + multi-projects :-)

A solution to the multi-arch + multi-project problem is what OE (OpenEmbedded)
uses; a hierarchy of arch/libc/target/image combinations. This enables
multi-arch + multi-projects in the same tree. But BR does not have the
equivalent of an OE image (a named set of predefined packages to put into
the rootfs). In BR you have to manually define your "image" in the
.config file. But this image, IMO, is not as "clean" as the OE image,
because a .config file defines much more than what packages are supposed
to be in your rootfs. And that makes me realize that the OE output directory
model is probably unsuitable for BR.

> A possibility would be to add a configuration option to set the output
> directory path, instead of passing O=. I don't have a strong opinion on
> this, but I'd prefer not to have both solutions. The fact that
> Buildroot has multiple solutions to do approximately the same thing is
> a large part of the confusion for our new users, and I would like to
> reduce this confusion.

I realize now that it takes more than a simple output-ARCH directory,
so I'd like to keep the current functionality with O=.
(Because BR should not be as complex as OE!)

Regards,
Bj?rn Forsman

[Buildroot] multiple architectures

[Peter Korsgaard]

>>>>> "Bj?rn" == Bj?rn Forsman <bjorn.forsman@gmail.com> writes:

Hi,

 Bj?rn> I realize now that it takes more than a simple output-ARCH
 Bj?rn> directory, so I'd like to keep the current functionality with
 Bj?rn> O=.  (Because BR should not be as complex as OE!)

Indeed. I think one of the main advantages BR has over OE is
simplicity - We should always keep that in mind before adding new
features.

-- 
Bye, Peter Korsgaard