[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[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

 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: