Mailing List Archive

Hi. Model

> /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/'
>

there is one drawback here - compiler version. Looks like gentoo
stores libc files in /usr/lib/gcc/arm-projectA-linux-gnueabi/1.2.3
so it will probably break something if you use different gcc for your projects.

> 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.
> What do you guys use?

I use 'arm-projectA-linux-gnueabi' approach. It works, but still not
ideal - For example, I can't just copy the whole folder to another
gentoo machine and continue use emerge-projectA there.

I would prefer toolchain to be in a single directory, like
codesourcery does. Maybe there is another solution, does anybody know?

Sergey

Hi Sergey,

On Mon, Jan 23, 2012 at 11:35:46AM +0400, Sergey Mironov wrote:
> Hi. Model
>
> > /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/'
> >
>
> there is one drawback here - compiler version. Looks like gentoo
> stores libc files in /usr/lib/gcc/arm-projectA-linux-gnueabi/1.2.3
> so it will probably break something if you use different gcc for your projects.

Yes, I remember falling into that trap before, with libgcc.a, etc. The
above layout assumed a single, static cross-compiler. Updates to the
cross-compiler would then necessitate rebuilding all the projects.

> > 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.
> > What do you guys use?
>
> I use 'arm-projectA-linux-gnueabi' approach. It works, but still not
> ideal - For example, I can't just copy the whole folder to another
> gentoo machine and continue use emerge-projectA there.

I don't anticipate much need to migrate /usr/cross-compiler to other
machines. As long as I keep the ebuilds for the cross-compiler
components, crossdev, and the packages, I should be able to rebuild any
given project from scratch.

I should probably set up a separate overlay per project to accomplish
that.

thx,

Jason.

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

On 01/03/2012 23:11, Bertrand Jacquin wrote:
> All the things I use are available in a tar tree here :
>
> http://people.meleeweb.net/~beber/gentoo/boest-gentoo.tgz
>
> Comments are welcome !

That's really very neat. My only observation is: have you considered
trying portage profiles to further simplify things? They are basically
cascadable and inherit from each other, so you can do some clever tricks
to reduce duplication (I use it on our servers quite extensively)

One of the things I haven't quite got under control is a simplified
patching process for ebuilds to avoid creating many local ebuilds. I'm
currently experimenting with using the /etc/portage/env type process via
bashrc. I use an "autopatch" type idea, and also read in extra bashrc
files per package. However, it's not very well integrated with my build
tracking process (but it works quite nicely...)

Good luck!

Ed W

D'ar lun 05 a viz Meurzh 2012 e 23 eur 03, « Ed W » he deus skrivet :
> On 01/03/2012 23:11, Bertrand Jacquin wrote:
> > All the things I use are available in a tar tree here :
> >
> > http://people.meleeweb.net/~beber/gentoo/boest-gentoo.tgz
> >
> > Comments are welcome !
>
> That's really very neat. My only observation is: have you considered
> trying portage profiles to further simplify things? They are basically
> cascadable and inherit from each other, so you can do some clever tricks
> to reduce duplication (I use it on our servers quite extensively)

This is a good idea yes. All the stuff is more a proof of concept for now
but this is an interesting approach but I only have one build server but
this evolve in some times. Using portage profile can be eas with own
overlay.

> One of the things I haven't quite got under control is a simplified
> patching process for ebuilds to avoid creating many local ebuilds.

I also have many patched ebuilds but I try to report them in gentoo
bugzilla to keep things maintained and so people can benefit.

> I'm
> currently experimenting with using the /etc/portage/env type process via
> bashrc. I use an "autopatch" type idea, and also read in extra bashrc
> files per package. However, it's not very well integrated with my build
> tracking process (but it works quite nicely...)

Why not using epatch_user in a generic (profile or bashrc) post_src_prepare() ?

function post_src_prepare()
{
function inherit() { : ; }

. ${PORTDIR}/eclass/eutils
}

--
Beber

On 05/03/2012 22:29, Bertrand Jacquin wrote:
> I also have many patched ebuilds but I try to report them in gentoo
> bugzilla to keep things maintained and so people can benefit.

Agreed - most such patches are usually more customisations of specific
things to the environment, eg I change the dnsmasq default timeouts to
better suit my environment. Also it can take a little while for changes
to be accepted or whatever

> Why not using epatch_user in a generic (profile or bashrc) post_src_prepare() ?
>
> function post_src_prepare()
> {
> function inherit() { : ; }
>
> . ${PORTDIR}/eclass/eutils
> }
>

That seems neat - however, wouldn't you also need to wrap it to prevent
it being applied twice by ebuilds which already run epatch_user?

Actually, can you explain how inherit works in this context? I'm not
sure I understand?

Thanks

Ed W