On Jun 25, 2007, at 12:06 PM, skaller wrote:
On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote:
It would be much better to have a single build system. I would gladly replace the whole thing ...
I am thinking of starting a new project (possibly as sourceforge) to implement a new build system. I think Erick Tryzelaar might also be interested. The rule would be: it isn't just for GHC. So any interested people would have to thrash out what to implement it in, and the overall requirements and design ideas.
My basic idea is that it should be generic and package based, that is, it does NOT include special purpose tools as might be required to build, say, Haskell programs: these are represented by 'plugin' components.
A rough model of this: think Debian package manager, but for source code not binaries.
I have been considering the same thing for some time, partly because
the specification properties of most available build systems are
terrible: XML is not a language (it is better as a back-end for a gui-
based build system); current plug-in systems (similar to what WAF
uses) are object-oriented and require a deep knowledge of the build
system API; others are manual hacks. One big thing to avoid are
cache-files: CMake, SCons, WAF, autotools, all use cache-files and
all run into problems when the cache files aren't cleaned or include
errors. (WAF has the best cache-file system--they are designed to be
human-readable.) I will gladly lend support to this.
An idea I have been kicking around is a hybrid between the autoconf
strategy and the commercial-setup strategy: add support for a
specification of program requirements, i.e.,