64-bit windows version?

Peter Tanski p.tanski at gmail.com
Mon Jun 25 12:48:40 EDT 2007

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.


More information about the Glasgow-haskell-users mailing list