Re: [gentoo-embedded] gentoo-embedded buildroot utility

[Ned Ludd]

On Wed, 2007-03-14 at 19:23 +0100, Christopher Friedt wrote:
> I may have already mentioned this once, but I don't see any harm in
> doing it again.
>
> Have any of you used Kuroo ? This is a similar idea - although not
> nearly as far along - for managing embedded system builds with portage.
>
> Are there any developer libraries for interfacing with Portage that are
> fairly available - [Java, C, C#, ... I've really never used python]
>
> ********
>
> As an gentoo user & embedded developer, I can see the massive benefits
> to both general purpose package management, as well as build automation
> for embedded systems, through the use of portage & emerge.
>
> Portage has a major advantage and should really be asserting itself more
> in the world of embedded package management. The crossdev utility is by
> far an excellent piece of work - I use it for practically every
> toolchain now.
>
> However, there are a few questions that I've been asked several times -
> (mostly by my boss), such as -
>
> i) why not just use OpenWRT, which will generage a filesystem image,
> download your sources, _and_ build a kernel automatically...
>
> ii) why not use that thing from openembedded.org ? ... same idea as above...
>
> Why not? because I think that portage is clearly better, the source is
> more current, dependencies are better resolved, more flexible, etc.
>
>
> What appears to be a constant theme, in terms of what the 'competition'
> has on gentoo-embedded, is an easy-to-use build system.
>
>
>
> The good news is, I've actually done some extensive work on this!
>
> I've been working on a _single_bash_script_ that is exceeding 2000+
> lines of code. What it does, is interactively help the user set up a
> buildroot and manage portage overlays for different targets. That is, a
> stage1 filesystem, a local portage tree, a cross-toolchain, etc.
>
> The reasons for this are:
>
> 1) portability across linux vendors (i.e. the developer does not need to
> run gentoo natively, only needs to chroot to get the advantages of portage)
>
> 2) separability from the main os - none of the host
> /etc/portage/package.* files are not adjusted - so there is practically
> nothing changed at all on the host machine except for the addition of a
> new buildroot directory.
>
> 3) extensibility - I'm seriously considering developing user interfaces,
> libraries, etc, all to make this _more_developer_friendly_ ... even a
> context free grammar for all possible buildroot / configuration
> operations. Likely any extensions to this will be done either in C
> (libs), Java, or C# ... maybe even an extension of some kind for
> Eclipse. This could be somewhat similar to Kuroo
>
> 4) enables embedded developers to simply manage their embedded devices
> using a portage overlay, in a very portable way.
>
> 5) easy generation of a root filesystem
>
>
> By basically mounting or systematically copying/destroying key portage /
> crossdev / configuration files to the chroot upon chroot (mount -n -o
> bind, etc). This (will / has) enabled the same buildroot to be used for
> _several_ configurations (portage overlays), targets (with versioned
> toolchains), as well as developer and stable profiles. I'm working in a
> way to automate compressed configuration backups as well, organized by
> date. Hopefully, this will all be SVN friendly too - except for device
> nodes of course :P
>
> The user is interactively prompted to select a target / toolchain, etc,
> these are all selected based on __tested__ compilations on each
> architecture using crossdev - a sort of build matrix like that from Dan
> Kegel.
>
> There is a list of toolchains for each architecture that were cleanly
> built using crossdev. I've only done a fraction of the build automations
> for X86, and it took something like 2 days.
>
> What's really interesting about this script, is that i've made the
> script copy itself to the chroot, upon every chroot, but with a
> different name. So when the program chroots, it actually calls itself
> upon transition with
>
> LIST=of \
> ENVIRONMENT=variables \
> chroot ${DIR} ${PROG2_NAME}
>
> which allows for a somewhat 'seamless' routine carryover - that is if
> the program needs to install a toolchain, it will pass certain
> environment variables once it moves to the chroot, etc.
>
> I think that this could be a pretty good addition to the embedded
> development utilities for gentoo.
>
>
> Please inform me if you have any interest in this project at all, I
> would be very happy to have any assistance or input.
>
>
> ~/Chris

Your project seems very similar to that of the former GNAP (sadly the
old GNAP developer is no longer with us)
http://www.gentoo.org/proj/en/base/embedded/gnap.xml

Anyway your goals are inline with ours for the most part.. So you may
want to consider becoming an embedded developer for gentoo. If that is
something that interests you come join us on irc in #gentoo-embedded on
irc.gentoo.org (point at this thread and work with us for better
integration) with portage/gentoo itself.

-- 
Ned Ludd <solar@g.o>
Gentoo Linux

-- 
gentoo-embedded@g.o mailing list