Peter Tanski wrote:
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:
- the initial bootstrap is done by hand. (your (1) above). All you need to
do is build stage 1 using an existing mingw-GHC. The stage 1 that you
build will be capable of creating native objects and binaries. Any hacks
you have to apply to do this part are certainly temporary.
- 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.
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'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.
I could be wrong. If I am wrong, then constructing a convincing argument might
be difficult, because it's a matter of details - the cumulative weight of things
you have to hack is too great. So go ahead and use VS or whatever; but please
think very carefully before doing so, because it's not cost-free. We're not
going to drop the mingw port of GHC, and it's hard to keep everything working as
it is. We'll have to import new hackers who understand VS builds, because none
of the current GHC maintainers do!
Use GHC as your C compiler, i.e. don't invoke CL directory from make,
and add the INCLUDE/LIB directories to the RTS's package.conf.
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
<compile/link command> <compile/link flags> <output> <source/object
files> <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:
<compile/link command> <compile/link flags> <output> <other flags>
<source/object files>
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.
It also adds one more layer of indirection a that delicate stage.
huh? GHC already invokes gcc, you need to change it to invoke CL anyway.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
