Ross Paterson
On Wed, Jun 04, 2003 at 12:16:19PM -0400, Isaac Jones wrote:
With that in mind, we need to make some decisions about what the build infrastructure will look like. To recap, I propose that we have
1) a "default" makefile system. Alastair Reid is working on one based on fptools' makefiles. We can provide a tool to generate a skeleton makefile system for new libraries.
2) an abstraction layer, perhaps like "distutils" for python combined with Debian's deiban/rules file which will allow us to build layered tools which will:
- Make it so that 3rd party library authors don't _have_ to change their build system - Make it easier for packagers to make Debian / Redhat / FreeBSD packages, - Make it easier for 3rd parties to distribute their libraries on their home pages (probably in a source tarball) - Make it easier for end users to download, install, and keep up to date 3rd party libraries
Sorry to be prosaic, but I would prefer to start at the bottom level, because there's a pressing need for a build system, and ideas there can be tested with code. 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.
I'm not too worried about 3rd party library authors being forced to change their build systems; nobody has one that works with all 3 compilers (except maybe Yale). And the information required by the common build system should be minimal.
Being a 3rd party library author, I am worried. Gtk+HS, for example, has a quite sophisticated build system. Adapting that to anything else would be quite some work. IMHO it is nice to have a build infrastructure that people can fall back on if they haven't got anything else, but to prescribe anything won't work. Cheers, Manuel