Ross Patterson wrote:

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.

Yes, we _almost_ have one, based on gnumake. But the complexity of making it work with Haskell systems as different as Hugs and GHC, on platforms as different as Unix/Linux and Windows, while providing flexible support for all kinds of pre-processors, submodules written in languages other than Haskell, and so on, became, in the end, quite daunting, to say the least. So we're currently out of steam. The last stumbling block, I believe, was something utterly silly like spaces in path names (quite common under Windows), that caused some carefully crafted snippets of shell code to fall over. Sigh.

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.

That's probably a good way to go. At least that has been our approach. (Our intention was (we've got parts of it working) to add functionality for distribution and packaging simply by adding extra make targets.)

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.

In our case, we didn't want to require the end user to fetch a build system separately. So, as always seem to be the case with make files, we intended our build system to be distributed with our libraries (and applications, it supports both). But the library (or application) writer only has to supply some more or less declarative specifications in a few key places: most of the build system can be copied verbatim. Somewhat crude (as make based systems tend to be), but it almost works for us. And with a little extra effort, I'm fairly confident we can make it work as intended also on Windows. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu

Manuel:

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.

I strongly agree with this. That's the beauty of Isaac's idea (adapted from python or debian or ...) of putting a script on top of it all. If it's sitting on top of an fptools make system, you use one version of the script; if sitting on top of the gtk+hs build system you use a slightly different version. (In both cases, the script should be fairly trivial because the makefiles do all the work.)

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.

This reminds me: can you recommend some make rules for use with c2hs so that I can add them to the fptools infrastructure. -- Alastair

On Thu, Jun 05, 2003 at 10:40:34AM +0100, Alastair Reid wrote:

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.)

That's the sort of thing I had in mind. Ideally the author would write a minimal definitions.mk containing only make variable settings specific to the library, and the build system would supply a script that invoked make on a generic Makefile that included definitions.mk in the middle.