64-bit windows version?

[Peter Tanski]

On Jun 21, 2007, at 11:48 AM, Simon Marlow wrote:
> Peter Tanski wrote:
>> If I could change one feature of the current system ... for known  
>> systems use autoconf only to determine what the $(build) system is  
>> and to ensure those programs are available, then jump into make  
>> which would call pre-set configuration makefiles for that system.
>
> So you'd hard-wire a bunch of things based on the platform name?   
> That sounds like entirely the wrong approach to me.  It makes the  
> build system too brittle to changes in its environment: exactly the  
> problem that autoconf was designed to solve.

Maybe this depends on the type of convenience you want to offer GHC- 
developers.  With the autoconf system they are required (for Windows)  
to download and install: Mingw, perl, python (for the testsuite),  
flex, happy, alex and some others I can't remember right now.  Oh  
yeah, GMP.  When I did that, autoconf gave me the convenience of  
having those programs somewhere in my $PATH and if autoconf found  
them I was good to go.  The way I would change things would not be so  
different, except that the developer would have to set up the build  
environment: run from under Mingw, etc.  The benefit would be that  
instead of testing all the extra things autoconf tests for--path  
separator, shell variables, big/little endian, the type of ld and the  
commands to execute compile--those would be hard-wired because the  
system is known.  When things break down you don't have to search  
through the long lines of output because you know what the initial  
settings are and can even rely on them to help debug Make.  This is  
the way it is done for several systems: NextStep (now Apple) project  
makefiles, Jam, and many of the recent build systems, including  
CMake, Scons and WAF.

Just last week I got an email from someone who had downloaded Cygwin  
and installed GMP but ran into problems compiling GHC because  
autoconf couldn't find the installed-GMP and tried to build the old  
GMP located in the rts directory instead--note: it fails under Cygwin  
for GMP_CHECK_ASM_W32, an autoconf macro.  Clear directions on where  
to put things would have solved this, or a build system that had  
better search capabilities--but I see your point about changing  
things too much (there is a very delicate balance to things as they  
are).

>> It does use a custom "configure" script written in Python (more  
>> consistently portable, no temporary files of any kind in $ 
>> (srcdir)) ...
>
> Adding a dependency on Python is already something I want to  
> avoid.  One way we try to keep the GHC build system sane is by  
> keeping the external dependencies to a minimum (yes I know the  
> testsuite requires Python, but the build itself doesn't).

I fought with myself about this for awhile--the end result will  
integrate into the main GHC configure.ac (as it should) but it will  
have to be much simpler.  I initially had a much more complex  
autoconf-based system but that created temporary files in $(srcdir)  
and it would not port well to other autoconf systems--even including  
extra .m4 code for the tests (I ran into trouble running autoreconf  
and even using a simple shell script that would run aclocal -Im4,  
autoheader, automake -a, and autoconf separately, when porting from  
autoconf 2.59 (OS X) to autoconf 2.61 (Ubuntu Linux) and autoconf  
2.52 (Mingw)--the point being that a developer would be able to run  
autoreconf and get the same thing back again).  The python script  
works well on all systems I have tested it on and I wanted to use  
python to help run the C-based testing framework and handle auto- 
tuning.  I can put all that into a shell script but for Windows it  
should be a DOS batch file, at least.

Windows developers should not be forced to run everything under Mingw  
or Cygwin.  There are two problems with $(srcdir): someone who wishes  
to work out of a darcs repository will have to do a full copy of the  
source directory if they don't have the ability to create a shadow  
copy; and, those environments are themselves quite brittle--depending  
on how you invoke Mingw, you may have a completely different $PATH  
setup and for a Windows-native build you would have to manually add  
the Windows tools to your path (calling vsvars32.bat, the file that  
sets up the path for the MS Tools, from under Mingw doesn't work-- 
maybe I've forgotten something).

> However, I admit I don't fully understand the problem you're trying  
> to solve, not having tried to do this myself.  The GHC build system  
> now uses Cabal to build libraries (actually Cabal + make + a bit of  
> autoconf for some libraries).  Why can't this method work for  
> building libraries on Windows native?  We must port Cabal to  
> Windows native anyway, and then you have a library build system.

It seems everyone has been looking for a replacement to autoconf for  
Cabal for quite some time now.  John suggested using a complete  
scripting language to do it and I had toyed with that prospect a  
bit.  A basic requirement would be that it is already available on  
the majority of architectures where GHC has not been ported.  A more  
practical requirement would be that it has a definite syntax for all  
architectures--no special shell quirks.  Things that fit this bill  
are JVM-based applications and Python--JVM being more portable.  I  
have to confess, I hate Java and I consider the language itself  
plebian, or at least parochial.  Two systems that would do better  
with this are Jaskell (http://jaskell.codehaus.org/) or SISC (the  
Scheme-to-Java compiler, at http://sisc-scheme.org/).  In any case, a  
good project would be a decent replacement for autoconf based on one  
of these.  Perhaps port Cabal to Jaskell?

I may have digressed there a little.  Sorry.  In any case, for  
Windows-GHC it seems impractical to require developers to have Mingw  
installed--the ported compiler will run through native-asm only so  
they won't need to have perl installed; only GHC and Yasm and VS  
(which is a long download but requires far learning for a Windows  
developer).  I can fairly easily change the library requirements for  
Windows because I am only porting to variations of the Windows platform.

>> What I hope you would agree on for Windows-GHC is a build that ran  
>> parallel to the autoconf-make system.
>
> What I hope is that we don't have to do this :-)

It's a really big job but it seems more complete in the end.  I think  
we talked about this before: the cross-compile to get the hc-files  
must use the Windows headers, then the hc-build script must be  
modified to use the windows toolset.  Both of these are quite  
invasive and messy to the current system--imagine the makefile code  
for DLL-building x10.  Once that is done the Windows-GHC will have to  
operate as an independent fork: I doubt many people will wish to do  
another hc-build of it though it would be a good idea to keep the  
files around.  What I propose is to start using a different build  
system starting with the hc-build script.  Whatever the end result  
is, GHC must be able to operate without Mingw and the GNU toolset.

> If we were to use something other than GNU make, we should do it  
> wholesale, or not at all, IMO.

Yeah.  Otherwise one system sits around and gets a few too many bugs  
for anyone to want to fix it up again, then it rots away, leaving a  
great many maggot-files of forgotten purpose scattered through your  
source code.  I spent quite some time searching, learning about and  
using different build systems.  John is right: aside from tracking  
dependancies, it would also be better to maintain the configuration  
and build system in a single language, as well.  The problem of build  
systems seems to be reaching a head outside these walls--I am  
beginning to see stuff on this all over the place.  I suggested a  
special build for Windows because Windows is a "special" system-- 
practically everything else (I haven't heard anyone talk of porting  
GHC to OS/2) is posix-based.  There is only one special system to  
maintain independently of posix and using, say, VS tools you will  
have a ready supply of experienced programmers who would be grateful  
for the opportunity to work with something familiar.

Cheers,
Pete