64-bit windows version?
p.tanski at gmail.com
Mon Jun 25 16:28:14 EDT 2007
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
> 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.
More information about the Glasgow-haskell-users