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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
