On 13/08/2008, at 20:34, Simon Marlow wrote:
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple
packages. It could be part of Cabal or a separate tool (for which
Cabal could, again, act as a preprocessor).
GHC is a special case: we already need a build system for other
reasons.
I agree. I just don't think that adding a full-fledged build system
to Cabal is the solution. In my experience, huge monolithic tools
which try to do everything never work well. I much prefer small,
modular tools. A Haskell-based build system is an interesting
project but why does it have to be a part of Cabal?
Hmm, but you said above "there should be a standard build system for
simple packages. It could be part of Cabal...".
On second thought, it shouldn't be part of Cabal :-)
Cabal has two parts: some generic infrastructure, and a "simple"
build system (under Distribution.Simple) that suffices for most
packages. We distribute them together only because it's convenient;
you don't have to use the simple build system if you don't want to.
My impression of Cabal is that it is a build system with a bit of
generic infrastructure. In particular, a large part of the .cabal
syntax is specified in terms of this build system and some of it only
really makes sense for this build system.
I think perhaps you're objecting to the fact that the "simple" build
system isn't so simple, and we keep adding more functionality to
it. This is true, but the alternative - forcing some packages to
provide their own build system - seems worse to me.
Cabal packages do provide their own build system; it's just that they
use Cabal syntax instead of, say, make. The advantage of doing this
is, of course, that Cabal's syntax is simpler. Adding things to the
"simple" build system erodes this advantage. Complex projects will
still have complex build systems - the complexity will be in
the .cabal files. If Cabal's goal is to be able to build any project
it will basically have to duplicate the functionality of autoconf,
automake, libtool, make and a couple of other tools *and* be just as
flexible. I think this is neither realistic nor necessary. So where do
we stop? And what about the packages that Cabal won't support when we
stop?
IMO, we should have stopped some time ago. A .cabal file should
describe a package, not how to build it. Building should be handled by
different tools with a clear interface between them and Cabal. If the
build system of choice needs additional information, then that
information should be provided in a separate file and not in the
package description.
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, "polluting" a package description with build
information seems wrong to me.
Roman
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
