I keep on referring to this as temporary because there are two
different builds here:
(1) the build using the old mingw-GHC, without option support for
CL; and,
(2) the build using the new Windows-native GHC.
Yes. And what I'm suggesting is the following - what I've been
suggesting all along, but we keep getting sidetracked into sub-
discussions:
- we adapt the current build system to use the native GHC. I
really don't
think this is hard, and it's way quicker than replacing
significant chunks
of the build system, as you seem to be suggesting.
I don't have to replace large chunks of the system, although I have
added several separate makefiles--an mk/msvc_tools.mk and mk/
build.mk.msvc (which configure will copy into mk/build.mk). It is
almost done (the current system, I mean)--although I do have one
detail question: Clemens Fruhwirth sent a patch to add shared library
support for all architectures, i.e., MkDLL -> MkDSO (in compiler/main/
DriverPipeline.hs). I haven't seen the patch after I did my last
pull, yesterday. So I assume it has not been applied yet. How do you
want autoconf to detect the shared library extension and libtool
support? AC_PROG_LIBTOOL does not seem to work well on OS X: OS X
libtool is Apple, not GNU (it is also a binary, not a driver-script
for libltdl); that macro failed the last time I built GMP and I had
to make shared libraries manually). This is precient because the
default build for Windows should be DLLs but I want the configuration
(at least) to mesh with the rest of the system: I wanted to add $
(libext) and $(shlibext); as it is, I vary them by a simple case in
*windows), *darwin*) or *) (unix) but this does not seem correct.
So the result is a build system that can build a win-native GHC
using another win-native GHC, but not necessarily build a win-
native GHC using a mingw GHC.
I could set it up so configure could detect which GHC is available
and build using that GHC (Mingw or Windows-native). (Just add a C-
compiler string to 'ghc -v' or 'ghc --version' and grep for it.)
I'm not against VS in particular - I'm against duplication. Build
systems rot quickly. By all means discuss a wonderful replacement
for the current build system -- I'm aware that the current system
is far from perfect -- but I'm not at all convinced that it is a
necessity for building win-native GHC.
VS is not necessary; it is aesthetic and may offer other benefits for
those who wish to hack on GHC. It would require many bits of glue
code and careful alignment of tasks so the entire build would not be
transparent to any but the most experienced VS programmers. It
would, however, be much easier to the more casual developer and it
may not be as brittle: shallow build settings, compiler settings,
source files included, a bureaucratic notion of ways, would be
available from a simple point and click. If I have time I will at
least do a prototype (base-compiler only) and see if people like it.
I could be wrong. If I am wrong, then constructing a convincing
argument might be difficult...
We'll have to import new hackers who understand VS builds, because
none of the current GHC maintainers do!
New blood! :) I'm joking--there have been forks of GHC in the past
but they generally don't last long because GHC moves too fast and
that's because the Architects are still at work. The only convincing
argument here would be a prototype that even the GHC maintainers
would be able to understand.
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
<output> <other flags>
while for cl running link.exe or link.exe, it is better to put all
the files at the end of the command line:
<output> <other flags>
Why is that a "conundrum"? GHC can invoke CL with the arguments in
whatever order it likes. Sorry, but this just seems like a trivial
detail to me.
Mingw GHC can't do that. I simply added some conditional changes to
the rules in mk/suffix.mk.
Cheers,
Pete
