[debian-installer] Build setup?
How should we design the `debian-installer' build system?
I think that it ought to be very granular, with a complex dependancy
structure, so that changing one thing doesn't involve a long rebuild
cycle before a testable image is generated. Makeing it work with the
`-j' switch would be a Good Thing, and should also be a goal.
Perhaps a non-recursive project Makefile(s) structure should be
cooked up as well. (Have yous read "Recursive Make Considered
Harmful"?)
Therefore, it ought to be implemented mostly in GNU Make. We can of
course construct complex commands using shell and/or perl scripts,
and call those from the Makefile's, but the scripts should not build
more than one target each, so that our Makefile's prerequisites
structure can hold the necessary information to restart a mostly
built run. It will save us lots of time during development. Nothing
will be rebuilt unnecessarily. (of course that will cut down on our
IRC time, but it's not a bad tradeoff really. I'm boring in IRC,
remember? It will spare you all!)
Some folks will call it very obfusciated... but surely they have
never looked at a `configure' script or the m4 macros that create
it... Speaking of which; I imagine we may need to use `autoconf' so
our system will build more easily on Hurd? (YTMAWBK)
It ought to take advantage of GNU Make's `include' directive, and be
quite modular. This way, each architecture's archdep stuff can be
sepped out into a module. Each logical stage of the build ought to
have its own module. I began doing that on that side branch I
created in the `boot-floppies' repository. Maybe some of that is
useable, if for nothing but an example.
We can finally do away with that `release.sh' crock, and have the
build setup put the files into the right place in a staging directory
to begin with.
For complex dependancies, I wonder about the following... will this
work? I've not researched it yet. (and I must remind; I'll not have
time to work much on this until next Summer, unless I cut back on
school hours over Winter and Spring... I might just do that.) I
don't know how to implement it yet. Details.
We build the base system by opening the .deb's into a chroot. What
if we use the *.list files on the LHS of autogen Make targets, and
the *.deb they came from on the RHS? Then, rather than erase all of
the chroot between builds, we leave it intact. If a new version of
a *.deb arrives at the developer's mirror, only that particular
*.deb needs to be re-unpacked and configured, letting Make handle
the dependancy.
A similar setup can be used for the other diskette images... the
main idea being to minimize the amount of image rebuilding needing
to be done when a small change is made to part of the system by a
developer. Of course, a `make distclean' and total from-scratch
rebuild will need to be done prior to releases being made, just to
ensure that the system will work correctly on any arbitrary hacker's
machine when they "apt-get source debian-installer".
Reply to: