[uClibc] Buildroot package placement policy/style question...

George Joseph gtj.member at peakin.com
Wed Jan 19 01:50:10 UTC 2005


Hmmm.  I didn't realize sed went both ways.

Seems to be two options then...

A: Like "sed" ... Common config/make in package with an option to build for build host, target host or both. 

B:  Two completely separate instances.  For the target host, put the config/make in package and build in build_*.  For the build
host, put the config/make in target with the other toolchain stuff and build in toolchain_build_*.

A is nice and compact.  B allows you to have a different version for the build host and target host.  I'd go with A until someone
has a reason to build with 2 different versions.

If we went with A, we'd probably still need a Config.in file in the target directory tree so you'd still see the option to build a
jffs2 filesystem for example in the target options config tree, but you'd also see the option to build the tools for the target host
under the package selection config tree.

Preference, Alternative?

-----Original Message-----
From: Erik Andersen [mailto:andersen at codepoet.org] 
Sent: Tuesday, January 18, 2005 5:07 PM
To: George Joseph
Cc: uclibc at uclibc.org
Subject: Re: [uClibc] Buildroot package placement policy/style question...


On Tue Jan 18, 2005 at 12:14:02PM -0700, George Joseph wrote:
> How should packages that are run on both the build host and target 
> host be handled?  I'm thinking about packages like mtd where you need 
> mkfs.jffs2 to run on the build host to create a fs, but also want the 
> same set of tools compiled to run on the target host.
>  
> Right now, cramfs, genext2fs, mtd and squashfs all get built in the 
> build_(armeb in my case)  directory even though they're compiled to 
> run on the local host.  Maybe they should be moved to 
> toolchain/toolchain_build? This way you could have versions compiled 
> for the target in build_ where they belong without conflicting with 
> the versions needed for the build process.

Some packages, such as sed, are built for both the host and
the target.  Such packages live under buildroot/package/
as you propose.

I didn't place genext2fs and friends under package since they seem to be entirely for the host system, and I did not anticipate a
time when thy might be needed on the target.

I admit this is somewhat of a weak area in my design for buildroot, but I couldn't think of anything much better,

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--




More information about the uClibc mailing list