On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote:
Well, at least the Makefile creation was a step (the first step?) into the wrong direction, IMHO. I'll run a GHC build to get some of those generated Makefiles and followup on cvs-ghc, but for a starter, Cabal shouldn't know anything about implementation-specific internal build systems; instead it should rely only on it's own metadata.
I'm not completely sure, but I think you may have misunderstood how Cabal's makefile generation currently works. It has no specific knowledge of GHC's build system, and it does rely on its own metadata.
I mean the GHC-specific template used for building the Makefile (Distribution/Simple/GHC/Makefile.in) and the function `makefile` in Distribution/Simple/GHC.hs (this function even spills out some some make rules in addition to what's in Makefile.in, which looks very wrong to me). Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. It'd be better to be able to run $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ... ... foo-exposed-modules = Control.Applicative Control.Arrow ... ... foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ... ... foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32 foo-extensions = CPP foo-ghc-options = -package-name base foo-nhc98-options = -H4M -K3M Basically, the .cabal file is just converted into some other format that may be included by another Makefile. And since it's a really simple output format, it could even be used by different implementations of make(1) or even other build tools. The `foo-' prefix just shields variables in the including Makefile. Take this output, write it to some cabalmetadata.mk, and then use a (GHC-specific) Makefile copied over into all library directories that does an include cabalmetadata.mk ... GHC_OPTS += $(foo-ghc-options) EXPOSED_MODULES = $(foo-exposed-modules) $(foo-impl-ghc-exposed-modules) EXTRA_LIBS = $(foo-extra-libraries) $(foo-$(HostOS_CPP)-extra-libraries) Thus, Cabal dumps the metadata, without knowing how it's used. All the remaining stuff are some (implementation specific) Makefiles relying on recursive variable expansion. I'll implement this for GHC when I've a little bit more spare time (in three or four weeks).
(in my other message I'm suggesting moving the Makefile generation into GHC's build system so that it could be made specific to GHC, though).
Generated files should be as simple, primitive and portable as possible. Generating complete Makefiles make things more difficult. And it doesn't matter wether they're generated by Cabal or by GHC's build system. If you've to tweak the build system, you don't want to tweak generators but just an existing Makefile.
Implementation-specific stuff (such as how to run the compiler) should be supplied by the implementation, not by Cabal.
This is what makes me unsure. Implementation of what?
The Haskell compiler. Or, to be more exact, the Cabal library shipped with the Haskell compiler (or some supplementary compiler-specific library -- I didn't think much about this part yet). However, my main concern is the usage of Cabal from within the GHC build system, so please just forget this part ;-)
Are you suggesting a redesign of Cabal, or just changing the way something works?
I don't think that a large redesign is necessary. It should just try to be as implementation-agnostic as possible. Ciao, Kili -- do yourself a favor and let the le(4)s rot on the junkpile of history... -- Henning Brauer