skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-
bit port of
mingw.
Why do you need mingw? What's wrong with MSVC++?
The largest problem is the build system: GHC uses autoconf with
custom makefiles. I have looked into porting the whole thing to a
Visual Studio project, using SCons (unreliable), CMake (limited
command line abilities--good for a one-shot build but really just a
"safe" lowest-common-denominator version of Make), Waf (another
python-based build system that started as a fork of SCons for the
KDevelop changeover from Autotools) and Jam. I would prefer to use
Jam but I'm afraid I would be the only one who would ever want to
support it. Nothing has the auto-configuration abilities you (John)
built into the Felix Interscript-based system but I do not porting
the build system (at least) to Interscript would go over well with
anyone else who wanted to maintain it and the build itself would
require heavy customisation. I have tested all of these on a small
scale (the replacement-Integer library). The best option seems to be
to create a VS project (not trivial--lots of glue) so a user may also
call that from Make (if under Mingw) or pure DOS.
There is also some gcc-specific code in the RTS (inline assembler,
use of extern inline, etc.) By the way, as of gcc-4.2 (I believe; I
know it is true for gcc-4.3) the use of 'extern inline' now conforms
strictly to the C99 standard so we will have to add the option '-
fgnu-89-inline' to get the old behaviour back--'extern inline' is
used in some of the headers. Converting those 'extern inline's to
'static inline' or best yet plain 'inline' would also solve the
problem. Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/
msg00006.html describes this in greater detail; his proposal was
implemented.
I don't think we'll be able to drop the mingw route either, mainly
because while
the MS tools are free to download, they're not properly "free", and
we want to
retain the ability to have a completely free distribution with no
dependencies.
I don't know of any completely free 64-bit compilers for Windows.
The Intel compilers are free for 30-day evaluation but everything
else is for Win32. For the base Win32-native port there are many
compilers available but I have mostly worked on using CL and Yasm
(assembler) as replacement back-end compilers for GHC.
There are people that want a Cygwin port too; personally I think
this is heading
in the wrong direction, we want to be more "native" on Windows,
using the native
object format and interoperating directly with the native Windows
tools.
Cygwin has a real problem with gcc: it is far behind everything else
(gcc-3.4.4, though Mingw isn't much better) and it doesn't look like
that will change anytime soon. It is also only 32-bit, I believe.
Cheers,
Pete
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
