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.
--
[email protected] mailing list
