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