[darcs-devel] Curl build issues

[John Meacham]

On Wed, Apr 16, 2008 at 11:47:52PM -0400, Gwern Branwen wrote:
> > The fact darcs is written in haskell shouldn't be a burden on people
> > that just want to use it and expect ./configure && make install to do
> > what they want. No matter what, it is annoying when programs differ from
> > the norm and people's first exposure to haskell shouldn't be annoyance
> > at having to look up some wacky new build system.
> 
> I don't think it's a big deal. Cabal comes with GHC and has for some
> time now; if you don't have such a GHC, your problems are bigger than
> Autotools vs Cabal. In addition: I don't think most people install
> from source, but rather binaries. Even the source-based distros would
> prefer cabal builds, I suspect. The only situation in which it'd be a
> problem is if you had a fellow who managed to install GHC, but somehow
> didn't have access to a package system with darcs also supplied in it
> (seriously, didn't most distros package GHC initially just to get
> darcs available?), and wants to compile by hand the darcs source.

This doesn't help that cabal just is not the right tool. It would be a
downgrade, autotools can take the same program and compile it on some
random obscure HPUX machine with some proprietary compiler just as
easily as a modern linux box. It is designed to adapt to the system at
hand, cabal can't even adapt to different versions of the same compiler
easily, and what happens when the next version of ghc is out? will
everyone have to rewrite their cabal files again to include special
cases for it? or will ghc's library structure now be set in stone for
all time because cabal files in the wild refer to it? neither sounds
very good.

Just like you can write simple programs and distribute them with just a
makefile, you can write some simple programs and distribute them with
just a cabal file. But that doesn't mean it is the right thing to do for
all programs, and I think encouraging it ultimately hurts both cabal and
haskell. 

> > > On the other hand, I've recently been playing with writing a build system
> > > in Haskell, which might be just the ticket for darcs.
> >
> > Excellent. Build systems are complicated and interesting projects.
> > Whatever the next big thing in build systems will be, it will require
> > some unique insight to be truely attractive. If any community can
> > germinate the seed of such an insight, I think it will be the haskell
> > one. I'd hate to see innovation stifled by an artificial need to use
> > cabal when so many other choices exist.
> >
> >         John
> 
> If you're interested in novel build systems, have you heard of Nix?
> <http://nixos.org/index.html>. I haven't had time to install and try
> it, alas, but reading the papers makes it sound really awesome and
> quite different from the Autotools paradigm or Cabal.

nix is a package manager. which is a different beast. I think this is
one of the major problems with cabal development. There are three very
different tasks that a software package might want:

1. package management of resulting code     (nix,rpm,apt,tarball,hackage)
2. actually building the code               (make,mk,ant,hmake)
3. configuring the build environment, stitching together the tools
needed for #2.  (autotools)

and no one seems quite clear on what they want cabal to be. or even
realize the disnction or the absolute need to be able to choose each
independently for a system to be acceptable.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈