Dear all
We have been groping towards releasing V1.0 of the current build system and
this is now about to happen with the resolution of a number of FPGA issues.
The build system in trunk has a number of advantages and disadvantages. Its
main adavantage is that it is what we currently know/love/hate but is not
without its drawbacks.
In its current form it only works with Debian/Lenny due to mostly to an
ancient buildroot impelmentation. Configuration for anything but standard
builds is somewhat unintuitive and very prone to breakage for non-obvious
reasons which has lead several knowledgeable developers to abandon the
effort of creating variants in frustration. Even when the configuration is
got right, the time to build a system (mostly due to the ancient buildroot
requiring a rebuild of toolchains every time) is so long as to inhibit
agile development. The main advantage in the current build system is the
thoroughness that it goes through to make a distribution, however, the
common use case is to do variant development and not to create distributions.
I have developed two branches named menuconfig & menuconfig2 that use the
kernel build infrastructure (actually a repurposed version from buildroot)
to drive a package model from an ncurses menu. The initial packages are
slightly modified versions of trunk's main directories. I have added other
packages (uboot, barebox, xloader) and extended others (select
lenny/squeeze rootfs). One design decision was to try and make the
buildroot initramfs image and rootfs image *once* and optionally patch
copies of these with the current kernel/modules. This means that a new
initramfs kernel does not require building a new buildroot from scratch
each time. Additionally, the new buildroot implements (+my patch) kexec so
can act as a second stage bootloader withall the kernel facilities one
likes. In my view this is better than a u-boot/barebox solution.
Discussion about whether this alternative (or another alternative?) build
system would serve the community better is opened. There are at least 4
other people who have used this system and given it initial approval. My
main concern is that this is very developer and less distribution centred
(though it should by a simple matter to upgrade any deficiencies) and may
not be what we want in trunk. Additionally there is no proper documentation
yet though its not hard to grok.
To use the new system, check it out, do "make menuconfig" inside the
branch, select your favourite options and type "make".
Packages are in directories under the package directory and include a
Config.in file and a <name>.mk makefile which adds to the overall build system.
If there is no great opposition, menuconfig2 which adds board support
(Balloon3/4 but maybe others) may be adopted in a few weeks.
Comments and opinions sought.
Nick Bane
(text/plain)