Ian Lynagh:
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty
wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library
packages.
Manuel
PS: Just for some more collateral damage. Did anybody check whether
the Mac OS installer support and the -unfortunately, only partially
working- support to compile for older OS X versions that I added to
the *makefiles* still works with the Cabal-based system? I doubt it.
Took me quite a while to get all this going, and I am not very well
motivated to spend a lot of time to figure out how it might work with
Cabal. IMHO using Cabal for anything but the libraries was a step
back for no good reason.
Do you mean the "rebuilding the tools with stage2" stuff? If so,
that's
an interesting example to pick, as that was the impetus behind
changing
how the build system worked for all the non-libraries/ghc.
Rebuilding with stage1 was already needed to build GHC with a builtin
readline. In general, it is a bad idea to build distributed binaries
of Haskell programs with the *bootstrap compiler*. It must be done
with the stage1 compiler. (If you are unsure why, I'll happily
elaborate.)
What I was mainly refer to is the building of GHC.framework with
xcodebuild and the accompanying packing with packagemaker. Building
for older versions of Mac OS X requires the MACOSX_DEPLOYMENT_TARGET
and related infrastructure.
Those changes made the build non-idempotent: we would build something
with the bootstrapping compiler, build some other stuff, then come
back,
clean it, and build it again with the in-tree compiler. This was a
little annoying at the best of times, as e.g. rerunning make at the
top
level would needlessly rebuild some stuff.
However, when my local changes meant that programs built by GHC
segfaulted, it was especially irritating to find that after
(hopefully)
fixing the bug I couldn't just run make in compiler/ or rts/, because
ghc-pkg etc now just segfaulted!
It was at that point that I half-reverted the changes, and later I
reimplemented something similar using Cabal. Now we make, for example,
ghc-pkg with the bootstrapping compiler in utils/ghc-pkg/dist-inplace,
and then later on we make it with the stage1 compiler in
utils/ghc-pkg/dist-install.
It's of course much cleaner to build inplace versions of everything
with the bootstrap compiler and separate distributeable versions with
stage1. I think we briefly talked about that during the run up to
6.8.3.
To answer your actual question: No, not having OS X yet I haven't
tested
it, but I did make an effort to keep it working. In mk/cabal-
flags.mk we
say:
USE_STAGE_CONFIGURE_FLAGS = \
...
$(addprefix --cc-option=,$(MACOSX_DEPLOYMENT_CC_OPTS)) \
$(addprefix --ld-option=,$(MACOSX_DEPLOYMENT_LD_OPTS))
which will hopefully do the trick, and (IMO) in a much cleaner, more
maintainable way than would have been possible with the old build
system.
I appreciate that you tried to preserve it, but things like those
usually don't work until explicitly tested and debugged. I think this
illustrates the issue I am having with the current process. I don't
think large changes that have not been properly tested should be
committed to the head. I appreciate that you cannot test everything
for every patch and don't have all the platforms at hand. That's why
major rejigging of the build system should be done on a branch. Then,
you can ask other people to test it, once it is all working well for
you. Ripping the guts out of the head and leaving some of them on the
floor just means everybody else is going to trip over them.
Manuel
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
