64-bit windows version?
simonmarhaskell at gmail.com
Fri Jun 22 07:03:49 EDT 2007
Peter Tanski wrote:
> 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.
In fact, to build a source distribution on Windows, there are only 3
dependencies: GHC, Mingw and (either MSYS or Cygwin).
To build from darcs, you also need: darcs, Happy, and Alex. To build docs, you
also need Haddock. To run the testsuite you need Python.
> 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.
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'm surprised - I thought conventional wisdom was that you should
write your build system to be as independent as possible from the name of the
build platform, so that the system is less sensitive to changes in its
environment, and easier to port. I can see how wiring-in the parameters can
make the system more concrete, transparent and predictable, and perhaps that
makes it easier to manage. It's hard to predict whether this would improve our
situation without actually doing it, though - it all comes down to the details.
On the other hand, we do hard-wire a lot of knowledge about Windows rather than
autoconfing it. This works because Windows is a fixed point; in contrast every
Linux system is different in various ways. So I guess I don't find it
problematic to wire-in what happens on Windows, but I do try to avoid it where
Getting back to the Windows native port, I'm pretty sure you're making more of a
meal of this than necessary. There's no need to port via HC files, unless I'm
> Whatever the end result is, GHC must be able to operate without Mingw
> and the GNU toolset.
That's the whole point of doing the port!
However, what I'm saying is that we can continue to use Cygwin as a set of tools
for doing the build. I don't see any problems with this (except that Cygwin is
slow and clunky), and it keeps the changes to the current system to a minimum,
and means we can continue to share the build system with Posixy systems. Here's
the plan I had in mind:
1. modify GHC so that:
a) it can invoke CL instead of gcc to compile C files
b) its native code generator can be used to create native .obj files,
I think you kept the syntax the same and used YASM, the other
alternative is to generate Intel/MS syntax and use MASM.
c) it can link a binary using the MS linker
2. modify Cabal so that it can use this GHC, and MS tools
3. modify the build system where necessary to know about .obj .lib etc.
4. modify the core packages to use Win32 calls only (no mingw)
5. Use the stage 1 GHC to compile the RTS and libraries
6. Build a stage 2 compiler: it will be a native binary
7. Build a binary distribution
Regarding autoconf, for the time being, just supply ready-made output files
(mk/config.h, libraries/base/include/HsBaseConfig.h, etc.).
More information about the Glasgow-haskell-users