Build system idea

[Simon Marlow]

John Meacham wrote:
> On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote:
>> The important thing about Cabal's way of specifying dependencies is that  
>> they can be made sound with not much difficulty.  If I say that my 
>> package depends on base==3.0 and network==1.0, then I can guarantee that 
>> as long as those dependencies are present then my package will build.  
>> ("but but but..." I hear you say - don't touch that keyboard yet!)
> 
> I can easily achieve this with autoconf or even nothing, I can simply do
> a test to see if a system is running fedora core 9 using ghc 6.8.2 and
> be assured that my package will build properly. But this misses the
> entire point, I want my package to build not on my exact system, I want
> it to build on _other_ peoples systems. People running with compilers and
> libraries and on operating systems I never heard of.

But you can only do that by carefully enumerating all the dependencies of 
your code.  autoconf doesn't help you do that - you end up underspecifying 
the dependencies.  Cabal makes you overspecify.  It's a 
soundness/completeness thing: Cabal is sound(*1), autoconf is complete(*2). 
  You complain that Cabal is incomplete and I complain that autoconf is 
unsound.  I'd like to make Cabal's dependency specs more complete, but I 
don't want to make it unsound.

(*1) as long as you specify dependencies with both upper and lower bounds
(*2) as long as you don't overspecify dependencies

I'd be interested in discussing how to improve Cabal's dependency 
specifications, if you have any thoughts on that.

> Again, I would like to see this as another option. I think there are
> interesting ideas in cabal about configuration management. But there
> needs to be room for alternates including old standby's like autoconf

autoconf isn't suitable as a replacement for Cabal's dependency 
specifications, because it doesn't specify dependencies.  I couldn't use an 
autoconf-configured package with cabal-install, for exmaple.

>> To generate a distro package from an autoconf package either the package  
>> author has to include support for that distro, or a distro packager has 
>> to write specific support for that package.  There's no way to do generic 
>> autoconf->distro package generation, like there is with Cabal.
> 
> In cabal you only get it because you convinced the cabal people to put
> in code to support your distro. Which isn't much different than asking
> the package manager too.

False!  All of the distro packaging tools for Cabal are separate entities 
build using the Cabal library.

> and there are many automatic package managers for autoconf style
> packages.
> 
> http://www.toastball.net/toast/ is a good one, it even downloads
> dependencies from freshmeat when needed. in fact, your projects can
> probably be auto installed by 'toast projectname' and you didn't even
> know it!

As I understand it, toast doesn't download and build dependencies, you have 
to know what the dependencies are.  (maybe I'm wrong, but that's the 
impression I got from looking at the docs, and if it *does* know about 
dependencies, I'd like to know how).

> http://encap.org/ - one I use on pretty much all my systems. since it is
> distro independent.

Again, dependencies are not tracked automatically, you (or someone else) 
have to specify them by hand.


>> That's the tradeoff - but there's still nothing stopping you from using  
>> autoconf and your own build system instead if you need to!
> 
> But it is a false tradeoff. the only reason one needs to make that
> tradeoff is because cabals design doesn't allow the useful ability to
> mix-n-match parts of it. I would prefer to see cabal improved so I _can_
> use its metadata format, its configuration manager for simple projects,
> autoconf's for more complex ones (with full knowledge of the tradeoffs)
> and without jumping through hoops.

No, it is a tradeoff.  We want packages on Hackage to be automatically 
installable by cabal-install, for one thing.  That means they have to say 
what their dependencies are.

> The fact is that it _is_ a big deal to replace cabal is the main issue I
> have. switching involves changing your build system completely. you
> can't replace just parts of it easily. Or integrate cabal from the
> bottom up rather than the top down. And it wants to be the _one true_
> build system in your project.

The counterexample again is the GHC build system, we integrate make and 
Cabal and autoconf, and we're planning to do more of it with make.

Have you thought about how to change Cabal to do what you want?  It's only 
code, after all :-)

> I'd like to see a standardized meta-info format for just haskell
> libraries, based on the current cabal format without the cabal specific
> build information. (this is what jhc uses, and franchise too I think)
> Just like the 'lsm' linux software map files. Preferably YAML, we are
> pretty darn close already and it will give us parsers in many languages
> for free. We already have several tools that can use the meta-info, jhc,
> cabal, franchise, hackage (for the web site layout) so it seems like
> abstracting it from the build info would be a useful step in the right
> direction.

I think we considered YAML, but I don't remember off-hand what the 
arguments against were.  Maybe someone else knows?

Cheers,
	Simon