cvs commit: fptools/ghc/driver/ghcMakefilefptools/ghc/driver/ghci Makefile - PS

[Manuel M. T. Chakravarty]

"Simon Marlow" <simonmar@microsoft.com> wrote,

> > The author claims that with the techniques in Section 5 of
> > the article it scales to big projects, but I haven't tried
> > it myself, so I don't know.
> 
> > I guess, the main problem is that rewriting the structure of
> > the whole fptools tree would be a lot of work.  (The
> > proposal that I made at the example of libexecdir, on the
> > other hand, would be a lot less painful to implement.)
> 
> I'd seriously consider rewriting the build system if we could somehow
> make it more modular or easier to understand (yes, I'm getting fed up
> with people complaining about it :-), so suggestions are welcome.
> 
> One thing I've considered would be to move all the project-specific
> stuff from fptools/mk/config.mk and into individual
> fptools/$(Project)/mk/config.mk files, and include *all* of them from
> fptools/mk/boilerplate automatically.  This would fix the modularity
> problem.

Have you ever looked at the build system of C->Haskell
(Compiler Toolkit).  I am not entirely satisfied with it and
some things, I would do differently in hindsight.  But is
based on having a xyz.mk file per project that sets
project-specific variables and a general PACKAGE variable
that is used in various places to adapt the configuration to
individual packages.

Cheers,
Manuel