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., <stdint.h>, gcc/cl/icl, things like that in a simple spec-document with dead-simple syntax, then let the build system handle the rest--it would know what to do for each architecture. That seems similar to the Debian package maker, right? What language are you thinking about using? Scheme seems good but the build-language itself might be different; gui-support should be available which says to me (horrors!) Java AWT--a cross-platform gui- supported build system (not an IDE) would rock the world because it doesn't exist. There are tons of Python packages out there (A-A-P, hasn't been updated since 2003; SCons, WAF, Bakefile (uses Python)). I don't know if this is possible in Felix. Other requirements might be: (1) never alter anything in the source directories--everything is managed through the build directory (2) ability to easily build separate targets from the command line, similar to 'make test_shifts'--externally scriptable. One thing other systems seem to fail at is building off the enormous trove of information in autoconf--it's right there, open source, and they reinvent the wheel when it comes to making configuration tests or finding platform information (config.guess is essentially a database of platform-specific information but is somewhat dated with regard to newer systems, including OS X). On that note, a different approach to configuration tests might be clearer knowledge about the compilers: all these systems build small C programs to test certain compiler characteristics and test for a 0 exit value. Well, CMake does actually 'read' the output files for some things, such as compiler version. Cheers, Pete