Ross:
I think an important requirement is that most of the build system should be shared, either distributed separately or bundled with the compilers, or a bit of each, but definitely not duplicated in each library. The library author should supply the absolute minimum information that is specific to the library, preferably in a declarative form.
This is what I'm aiming for with the fptools infrastructure (see fptools/libraries/X11 in CVS) I'm successfully building several libraries off a single fptools CVS copy. Some of the remaining issues are: 1) I'd like source distributions to be reasonably complete so, for now, I plan to include a complete copy of fptools in each tarfile. Ideally, this would become a separate package (probably called fpconfig) but this requires us to choose a standard place where fpconfig is installed so that the makefiles can refer to it. (Hmmm, or fpconfig includes a program /usr/bin/fpconfig-info which returns the necessary information?) 2) You need to provide your own copies of: $top/Makefile $top/mk/version.mk $top/mk/boilerplate.mk $top/mk/target.mk Ideally, there'd be just one or two files (I think this can be achieved fairly easily. I'm at the stage where I'm so glad anything works at all that I lost the energy to push further.) 3) The configure script is in fptools. This means a large chunk of boilerplate is shared by many people but also means that there's no ability to customize it by: - adding a test for a new feature - specifying what version of a given tool is needed (and having configure fail if it's not present). It seems like the fix will be to have a very, very minimal configure script in every project which #includes ${fpconfig}/configure.in -- Alastair