Version control systems

[Manuel M T Chakravarty]

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