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

[Christopher Friedt]

Hi Nedd,

That's a very good suggestion - I'll start signing on to IRC as well. 
I'm sure I could learn quite a bit from the rest of the g.e. developers, 
and hopefully my work could be of benefit to others as well.

cheers,

~/Chris

Ned Ludd wrote:
> 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.
>
-- 
gentoo-embedded@g.o mailing list