64-bit windows version?

Peter Tanski p.tanski at gmail.com
Fri Jun 22 10:42:56 EDT 2007

On Jun 22, 2007, at 9:45 AM, Simon Marlow wrote:

> skaller wrote:
>> On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote:
>>> Ok, you clearly have looked at a lot more build systems than I  
>>> have.  So you think there's a shift from autoconf-style "figure  
>>> out the configuration by running tests" to having a database of  
>>> configuration settings for various platforms?

I shouldn't overstate the situation: the other "complete" build  
systems, CMake and SCons do have autoconf capabilities in the way of  
finding headers and programs and checking test-compiles, the basic  
sanity checks--CMake has many more autoconf-like checks than SCons.   
Where they differ from the automake system seems to be their setup,  
which like Make has hard-coded settings for compilers, linkers, etc.   
(Some standard cmake settings are wrong for certain targets.)  I  
don't know if you have any interest in pursuing or evaluating CMake  
(certainly not now) but the "standard" setup is stored in a standard  
directory on each platform, say, /usr/share/cmake-2.4/Modules/ 
Platform/$(platform).cmake and may be overridden by your own cmake  
file in, say, $(srcdir)/cmake/UserOverride.cmake.

The preset-target-configuration build model I was referring to is a  
scaled-down version of the commercial practice which allows you to  
have a single system and simultaneously compile for many different  
architecture-platform combinations--once you have tested each and  
know how everything works.  For the initial exploration, it is a  
different (more anal) strategy: before invading, get all the  
intelligence you can and prepare thoroughly.  The GNU-Autoconf  
strategy is to keep a few troops who have already invaded many other  
places, adjust their all-purpose equipment a little for the mission  
and let them have at it.  My gripe is that their equipment isn't very  


More information about the Glasgow-haskell-users mailing list