decisions on building infrastructure

[Alastair Reid]

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