Re: [gentoo-embedded] multi-project workflow

[Bertrand Jacquin]

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