64-bit windows version?

[Peter Tanski]

On Jun 25, 2007, at 3:34 PM, skaller wrote:

> On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote:
>
>>> Maybe some gcc mimicing cl wrapper tailored specifically for GHC
>>> building system could help? One more layer of indirection, but
>>> could leave ghc driver relatively intact.
>>
>> That's a good idea!  Do you know if or how the mingw-gcc is able to
>> do that?  Does mingw-gcc wrap link.exe?
>
> There's more to portable building than the build system.
> For example, for C code, you need a system of macros to support
>
> 	void MYLIB_EXTERN f();
>
> where MYLIB_EXTERN can be empty, say  __declspec(dllexport)
> on Windows when building a DLL, and  __declspec(dllimport)
> when using it. This is *mandatory*.

Of course--one thing I would add to a build system, instead of  
compiling little C files and testing the return value to detect some  
compiler functionality, is the ability to read builtin macros, say,  
by telling the compiler to dump all macros like 'gcc -E -dM'  and  
then read through the macros.

As for the Windows-native build, I am pretty far long with that but  
the idea was to hijack the "gcc" executable with a script that would  
convert the gcc arguments to cl arguments.  The one thing such a  
script would not do is compile everything at once.  So far that is  
one thing I am adding to the Make system here: since dependancy  
generation is good for Haskell files but is not necessary for C files  
since I can bunch the C sources together with the compiler flags and  
pass them cl all at once in a command file.  This should be faster  
than Make.

> The build system controls the command line switches that
> turn on "We're building a DLL" flag. A distinct macro is needed
> for every DLL.

That is part of the modifications to the runtime system (RTS).

> In Felix, there is another switch which tells the source
> if the code is being built for static linkage or not:
> some macros change when you're linking symbols statically
> compared to using dlsym().. it's messy: the build system
> manages that too.

Sometimes this is better in header files and change the macros with  
defines the build system passes to the c compiler but Felix's system  
is much more flexible than that (it builds the source files  as  
interscript extracts them, right?).

> Building Ocaml, you have a choice of native or bytecode,
> and there are some differences. Probably many such things
> for each and every language and variation of just about
> anything .. eg OSX supports two kinds of dynamic libraries.

GHC's interpreter (GHCi) does have to be built.  I have not found a  
libReadline DLL, but I am sure I can scrounge something--possibly  
from Python since they had this same problem back around 2000.

> The point is that a 'Unix' oriented build script probably
> can't be adapted: Unix is different to Windows. The best
> way to adapt to Windows is to use Cygwin.. if you want
> a Windows native system, you have to build in the Windows
> way and make Windows choices. A silly example of that
> is that (at least in the past) Unix lets you link at
> link time against a shared library, whereas Windows
> requires to link against a static thunk ..
> so building a shared library produces TWO outputs
> on Windows.

I am building with Mingw because that is better supported by the GHC  
build system (Cygwin is somewhat defunct); the end result should  
build from source in Visual Studio/Visual C++ Express.

Cheers,
Pete