[darcs-devel] Curl build issues

Mon Apr 21 01:51:15 UTC 2008

On 2008.04.18 04:27:56 -0700, John Meacham <john at repetae.net> scribbled 4.8K characters:
> 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.

Great. Go and compile Darcs on 'some random obscure HPUX machine with some proprietary compiler' and tell us how it goes.

> 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.

I'll believe that Cabal is hurting Haskell when I see an Autotools-based Hackage, an Autotools-based cabal-install; when I see people complaining about how cabal files are impossible to understand, and when I see #xmonad full of people with installation problems because of Cabal - more full than I ever saw #ratpoison or #stumpwm (both of which were Autotools based). I'll believe it when the Autotools devs start caring at all about Haskell needs; I'll believe it the first time I take a bit-rotten Autotools Haskell package and find it *easier* to update than the equivalent cabalized package. Ultimately, I judge by results. And I am not impressed by Autotools.

> > > > 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

No, they're all three aspects of the same thing, which the cabal devs realize. If you had read the Nix papers, you'd've learned that Nix can do the things it does only because it interferes with the build process to guarantee that built packages only link in the (referentially-transparent) library and executable paths that they declared themselves to use.

--
gwern
NSOF to Patel GOSIP electronic 127 DI Ingram Gamma Keyhole
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20080420/615eab54/attachment.pgp 