64-bit windows version?

[Peter Tanski]

On Jun 26, 2007, at 4:59 AM, Simon Marlow wrote:

> Peter Tanski wrote:
>
>> I keep on referring to this as temporary because there are two  
>> different builds here:
>> (1) the build using the old mingw-GHC, without option support for  
>> CL; and,
>> (2) the build using the new Windows-native GHC.
>
> Yes.  And what I'm suggesting is the following - what I've been  
> suggesting all along, but we keep getting sidetracked into sub- 
> discussions:
>
>  - we adapt the current build system to use the native GHC.  I  
> really don't
>    think this is hard, and it's way quicker than replacing  
> significant chunks
>    of the build system, as you seem to be suggesting.

I don't have to replace large chunks of the system, although I have  
added several separate makefiles--an mk/msvc_tools.mk and mk/ 
build.mk.msvc (which configure will copy into mk/build.mk).  It is  
almost done (the current system, I mean)--although I do have one  
detail question: Clemens Fruhwirth sent a patch to add shared library  
support for all architectures, i.e., MkDLL -> MkDSO (in compiler/main/ 
DriverPipeline.hs).  I haven't seen the patch after I did my last  
pull, yesterday. So I assume it has not been applied yet.  How do you  
want autoconf to detect the shared library extension and libtool  
support?  AC_PROG_LIBTOOL does not seem to work well on OS X: OS X  
libtool is Apple, not GNU (it is also a binary, not a driver-script  
for libltdl); that macro failed the last time I built GMP and I had  
to make shared libraries manually).  This is precient because the  
default build for Windows should be DLLs but I want the configuration  
(at least) to mesh with the rest of the system: I wanted to add $ 
(libext) and $(shlibext); as it is, I vary them by a simple case in  
*windows), *darwin*) or *) (unix) but this does not seem correct.

> So the result is a build system that can build a win-native GHC  
> using another win-native GHC, but not necessarily build a win- 
> native GHC using a mingw GHC.

I could set it up so configure could detect which GHC is available  
and build using that GHC (Mingw or Windows-native).  (Just add a C- 
compiler string to 'ghc -v' or 'ghc --version' and grep for it.)

> I'm not against VS in particular - I'm against duplication.  Build  
> systems rot quickly.  By all means discuss a wonderful replacement  
> for the current build system -- I'm aware that the current system  
> is far from perfect -- but I'm not at all convinced that it is a  
> necessity for building win-native GHC.

VS is not necessary; it is aesthetic and may offer other benefits for  
those who wish to hack on GHC.  It would require many bits of glue  
code and careful alignment of tasks so the entire build would not be  
transparent to any but the most experienced VS programmers.  It  
would, however, be much easier to the more casual developer and it  
may not be as brittle: shallow build settings, compiler settings,  
source files included, a bureaucratic notion of ways, would be  
available from a simple point and click.  If I have time I will at  
least do a prototype (base-compiler only) and see if people like it.

> I could be wrong.  If I am wrong, then constructing a convincing  
> argument might be difficult...
> We'll have to import new hackers who understand VS builds, because  
> none of the current GHC maintainers do!

New blood!  :)  I'm joking--there have been forks of GHC in the past  
but they generally don't last long because GHC moves too fast and  
that's because the Architects are still at work.  The only convincing  
argument here would be a prototype that even the GHC maintainers  
would be able to understand.

>> Certainly doable but it does present a conundrum: for the old GHC  
>> (without builtin cl-support) the order for compilation seems to be:
>> <compile/link command> <compile/link flags> <output> <source/ 
>> object files> <other flags>
>> while for cl running link.exe or link.exe, it is better to put all  
>> the files at the end of the command line:
>> <compile/link command> <compile/link flags> <output> <other flags>  
>> <source/object files>
>
> Why is that a "conundrum"?  GHC can invoke CL with the arguments in  
> whatever order it likes.  Sorry, but this just seems like a trivial  
> detail to me.

Mingw GHC can't do that.  I simply added some conditional changes to  
the rules in mk/suffix.mk.

Cheers,
Pete