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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
