beber at meleeweb
Mar 1, 2012, 3:11 PM
Post #4 of 7
(629 views)
Permalink
|
Hi,
This is a good question that I try to resolv for some times, and
actually here is the solution I use.
For my use, this is a bit more complex than one toolchain for multiple
projects as I use different toolchains for one project, and have many
projects.
So I decline this in (what I call) PLATFORM and VARIANT that I call
PLATFORM-VARIANT.
PLATFORM is generally a hardware type and VARIANT the main project.
For exemple I have :
- PLATFORM=alix3-i586 VARIANT=maintenance that use i586-pc-linux-gnu- toolchain
- PLATFORM=alix3-i586 VARIANT=firmware that use i586-pc-linux-uclibc- toolchain
Toolchains are created with crossdev (without any patches or specific
things).
Then my bunch of scripts. This is a not really completed and some parts
are hardcoded (aka ROOT=/data/cross).
Once toolchains are made, I use variant-init that create :
$ROOT/$PLATFORM/$VARIANT/etc
$ROOT/$PLATFORM/$VARIANT/etc/make.profile -> /usr/portage/profiles/embedded
$ROOT/etc/portage/make.conf-$PLATFORM-$VARIANT
$PLATFORM-$VARIANT-emerge -> emerge-wrapper
$PLATFORM-$VARIANT-q -> wrapper-q
$PLATFORM-$VARIANT-etc-update -> wrapper-etc-update
The ROOT for each project is /data/cross/$PLATFORM/$VARIANT
$PLATFORM-$VARIANT-q and $PLATFORM-$VARIANT-etc-update are simple
wrapper to q and etc-update that performs things in ROOT.
All the portage configuration goes into $ROOT/etc to simplify things,
let's talk later about how to have specific things for PLATFORM and
VARIANT.
$PLATFORM-$VARIANT-emerge (the symlink) is mostly a wrapper to emerge-wrapper from
crossdev that export some variables :
- PORTAGE_CONFIGROOT=/data/cross/$PLATFORM/$VARIANT
- ROOT
- SYSROOT
- original CHOST and ELIBC
This is also responsible to sync /data/cross/etc/portage to
/data/cross/$PLATFORM/$VARIANT/etc/portage with some variances :
All files in /data/cross/etc/portage that have leading name
*-$PLATEFORM-$VARIANT are priorise, then *-$PLATEFORM
So I get then following in my /data/cross/etc/portage :
/data/cross/etc/portage/package.use/app-shells
/data/cross/etc/portage/make.conf-alix3-i586-firmware
/data/cross/etc/portage/make.conf-alix3-i586-maintenance
/data/cross/etc/portage/make.conf-desktop-lemonhead
/data/cross/etc/portage/make.conf-kvm32-firmware
/data/cross/etc/portage/make.conf-kvm32-maintenance
/data/cross/etc/portage/package.mask/sys-apps-alix3-i586-firmware
/data/cross/etc/portage/package.mask/sys-apps-kvm32-firmware
..
In this case, if I call alix3-i586-firmware-emerge then only
/data/cross/etc/portage/make.conf-alix3-i586-firmware is move in
/data/cross/alix3-i586/firmware/etc/portage/make.conf, all other are
ignored
This is to simplify portage configuration tree and avoid effort
duplication.
Then I have a specific make.conf that is sourced by all others for the
same reason. Specific things are done in each VARIANT make.conf, generic
in main one.
Specific set CHOST, ARCH, E_MACHINE, ELIBC, USE and CFLAGS
While generic have all the rest :
- CBUILD
- HOSTCC
- FEATURES : collision-protect sandbox buildpkg noman noinfo nodoc
-news -assume-digests fixlafiles
- ROOT
- SYSROOT
- CFLAGS
- CXXFLAGS
- LDFLAGS
- PKGDIR
- PORTAGE_TMPDIR
- PKG_CONFIG_PATH
- PORTDIR
- DISTDIR
- EMERGE_DEFAULT_OPTS
- MAKEOPTS
- GENTOO_MIRRORS
- FETCHCOMMAND
- ...
SYSROOT is always crossdev tree (for libtool and default gcc options).
See #404529
While packages are build for ROOT with a SYSROOT different to ROOT, I
use a specific bashrc that determin package SYSROOT dependencies and
unpack .so .a and .h files to $SYSROOT (/usr/<toolchain>) as all my
builded packages are FEATURES=buildpkg
I keep trace of unpacked files and remove them from SYROOT at the end
(with some exclusion (glibc, bintuils, linux-headers, gcc ...)).
And another tool toolchain-clean that list unknown files in SYSROOT to
keep things clean.
It also fix .la files to use the SYSROOT as ROOT
This bashrc also rsync $PORTAGE_CONFIGROOT/etc/portage/files to $D for
generic configuration files or others things that are unrelated to
generic gentoo utilisation.
I added some features to sstrip files and/or upx them, you just have to
declare do_upx or do_sstrip in env portage files.
All the things I use are available in a tar tree here :
http://people.meleeweb.net/~beber/gentoo/boest-gentoo.tgz
Comments are welcome !
Beber
D'ar lun 23 a viz Genver 2012 e 00 eur 37, « Jason » he deus skrivet :
> All,
>
> I'm getting back into embedded projects and thus, gentoo/crossdev.
> Things have changed a bit since I last used it (~4 years ago). This:
>
> $ crossdev -S -t arm-none-linux-gnueabi
>
> worked out of the box. Awesome! It looks like I'll want to use
> arm-none-linux-gnueabi-emerge to build the target system, but before I
> get started, I have a question.
>
> How do folks out there handle multiple projects with the same toolchain?
> I'm thinking, since crossdev worked so well, to just build a
> 'arm-projectA-linux-gnueabi' and then 'arm-projectB-linux-gnueabi' to
> keep the roots separate.
>
> My other idea was use symlinks:
>
> /usr/
> arm-none-linux-gnueabi/ -> projectA/
> arm-none-linux-gnueabi.orig/
> projectA/
> projectB/
> ...
> projectN/
>
> with arm-none-linux-gnueabi.orig/ being the original contents after
> crossdev built the toolchain. As I create projects, I would 'cp -a
> arm....orig/* projectN/'
>
> What do you guys use?
>
> thx,
>
> Jason.
>
--
Beber
|
signature.asc
