On Mon, 2007-11-05 at 12:47 +0100, Henning Thielemann wrote:
When Cabal development started I suggested to use Haskell code as configuration file, because there will be much extensions and the package description will not fit into a simple syntax soon.
So of course there is a trade-off to be made in the expressiveness of the language used for package descriptions & build procedures. My experience with build systems (and as a gentoo packager I've seen quite a few) tells me that a full turing complete language gives developers too much rope with which to hang themselves. Developers make packages which work on their systems; they cannot be expected to test in lots of different environments. So inevitably platform-specificisms creep in because there is no easy way to check for their absence (you'd have to actually go and build on a dozen different platforms). With a less expressive language that hides platform details there is more wiggle room for the packaging system to interpret the package in a way that makes sense for different platforms. The one place we do have general Haskell code in in Setup.hs files. I've seen quite a few of these now and almost every single non-trivial Setup.hs is wrong in some respect. They work in the normal case on the developers machine but fail when building a distro package (where the build and install steps are separated) or would fail on windows or a myriad of other things. By contrast when we have some bug in Cabal on some platform we can fix it in one place, not in the Setup.hs file of every single package.
This suggestion was rejected because the Package description should be readable by an IDE. With the flags and package version comparison we move quickly to a Turing complete scripting language in form of a package description. :-)
It's pretty important that it never gets there :-).
Btw. does the Setup.hs script still serves a purpose?
Some, but as little as possible. I'd expect only 10% of the most complex packages will need to use them in future. Duncan