GHC hacking in Windows -> too much pain

[Ian Lynagh]

On Wed, Aug 22, 2007 at 01:54:07PM +0100, Neil Mitchell wrote:
> 
> We had similar problems in Yhc, so decided to move to Scons to have a
> properly cross platform and consistent build system. My only advice
> from that experiment is _never_ use Scons.

:-)

> Our current plan is to move
> to a hand-rolled Haskell build system, but we still have no idea how
> that should work.

It's not completely infeasible that building GHC 6.10 could mean running
one ./Setup {configure,build,install}, which would do likewise for each
of the compat, GHC1, RTS, libraries and GHC2 Cabal packages. Hmm, it
would be a little ugly as we can't call "./Setup configure" of one phase
before we've done "./Setup build" of the previous phase.

We'd need to
* fix http://hackage.haskell.org/trac/ghc/ticket/930 and
  http://hackage.haskell.org/trac/ghc/ticket/910, or make Cabal do
  its own dep analysis and use ghc -c rather than ghc --make
* make building when little or nothing has changed faster, i.e. either
  ghc --make would need to write its dependency graph to a file (to
  avoid needing to rerun the preprocessor on everything) or Cabal would
  have to keep all the preprocessed files in dist/. It might be worth
  Cabal keeping its dependency graph in dist/ anyway.

You'd then be able to build without make (probably we'd still have
Makefiles, but trivial ones that just cut down the typing slightly).

configure scripts (called by "./Setup configure") are another story, of
course. On the other hand, I think a reasonable proportion of our
configure stuff is written by us anyway (or at least copied from
elsewhere, but in our source tree rather than bundled with autotools),
so maybe re-implementing it wouldn't be such a problem. I know Malcolm
is also interested in not being dependent on autotools.


Thanks
Ian