[darcs-devel] Curl build issues

David Roundy droundy at darcs.net
Wed Apr 16 16:09:17 UTC 2008


On Wed, Apr 16, 2008 at 08:59:19AM -0700, Jason Dagit wrote:
> On Wed, Apr 16, 2008 at 7:22 AM, David Roundy <droundy at darcs.net> wrote:
> > On Wed, Apr 16, 2008 at 01:47:28AM -0400, Gwern Branwen wrote:
> > > So, my recent efforts to Cabalize Darcs have been going fairly well. I
> > > now have a setup which allows me compile from an sdist tarball through
> > > Cabal and not the GNUmakefile. But there are some puzzling problems and
> > > changes.
> >
> > Warning... I don't like cabal, and am unlikely to apply cabalization
> > patches without a decent reason.  I'm not sure what would qualify as a
> > decent reason, but the only reason I could imagine is a libdarcs.
> 
> I think I know why you dislike Cabal as a replacement for make for darcs,
> but do you also feel that duplicating the build system in both cabal and
> make is unreasonable?  Certainly, it's no fun to maintain redundant build
> systems, but if others, say Gwern, were willing to keep the "optional" Cabal
> build system running and to also get it working initially how would you feel
> about it?
>
> I chatted with Gwern a little bit on IRC about cabal and I was actually
> encouraging Gwern because:
> 1) I know you want to have less and less involvement in your maintainer role
> for darcs.
> 2) In the past you've been willing to accept some optional, or
> non-mainstream, changes to darcs as long as someone else did the work.
>
> As you're probably already aware, many Haskellers feel that the darcs build
> system is messy and would be better off using the build tools invented in
> the Haskell community.  This sentiment is perhaps a bit of "Not Invented
> Here" syndrome[1].  I used to feel this way myself, but from conversations
> with you and through more experience with darcs I've come to see the value
> of the current build system.  With that said, I think you should accept the
> cabalization.  I think it's a step in the right direction for encouraging
> more active development by seasoned Haskell developers; the sort of
> programmers that frequent #haskell and haskell-cafe at .  I also think it will
> help cabal grow into a mature build system with some good "real-world"
> applications using it.  But, I'm not saying we need to, or should, get rid
> of the make system for now.  Instead, we add cabal and only support it for
> people like Gwern that are willing to keep it up to date with no promises
> from you that it will work in any given release.

The problem is that cabal doesn't try to replace darcs' build system.  It
doesn't support the concept of configure tests, and doesn't do anything
useful that the darcs build system does.  We could have an "optional" cabal
build, but it would beuntested, and by the nature of cabal, it would be
fragile.  I'd rather have a more robust build system, and since darcs
already has one that's more robust than cabal, using cabal seems like a
step in the wrong direction.

In the interest of spending less time maintaining darcs, I'd prefer to not
include a redundant build system that is known to be hard to maintain.
Either it's going to be broken much of the time, or I'm going to have to
fix it when it breaks.

> On the other hand, I've recently been playing with writing a build system
> > in Haskell, which might be just the ticket for darcs.
> 
> I would like to discourage you from creating yet another build system.  I
> have no doubt that you could do a stellar job on dabs (David's advanced
> build system ;), but I think your grey matter and spare programming time is
> better spent on tasks that others are not as well suited for.  For example,
> we would all appreciate you helping the Haskell community at large better
> understand darcs so that you could one day fully transition out of
> maintainership without affecting the long term success of darcs.  I also
> firmly believe that any efforts to make a build system would be better spent
> improving an existing build system instead of starting over.  And we all
> need to be caution and avoid NIH tendencies.

Actually, pointless programming is relaxing, which is why I took up the
project.  It's rather encouraging to note that a couple of days of coding
can pretty easily surpass the ease of use of cabal (probably largely
because I only support ghc).

Switching our configure tests to Haskell is not a bad idea, as the current
system is pretty ugly to hack on.  Since cabal doesn't support configure
tests, if you want an improved system, the only option is to write one
ourselves.
-- 
David Roundy
Department of Physics
Oregon State University


More information about the darcs-devel mailing list