Version control systems

[Matthias Kilian]

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