[darcs-devel] Curl build issues

[Jason Dagit]

On Wed, Apr 16, 2008 at 9:09 AM, David Roundy <droundy at darcs.net> wrote:

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


If included, I would say we rely on Gwern to keep it working for now.  And
if volunteers (read, Not-David), don't want to keep it working then we could
chuck it at that time (assuming having a non-working cabal file is creating
a problem).  You know what including it entails more than me, but that's how
I would hope it can work.  Those who don't want cabal can ignore it and
those that do can deal with it breaking and whatnot.

Maybe it would even be worthwhile to assign someone to partial maintainer
roles?  For example, someone is in charge of reviewing changes to the build
system and keeping it working smoothly and you don't actually review those
patches.  This designated person wouldn't even need apply permission, they
would just need to sign off on patches that touch the build system(s).  With
the rule that you don't review that part of patches and make it clear when
patches affecting the build come in that you're not going to accept them
until someone (a designated person) takes the time to approve them.  It may
sound very formal, but we could experiment with it.  And not just for this
detail.  Maybe it's how darcs should operate.  Have we tried this in the
past?  I certainly think for this to work we need to assign someone specific
as to avoid social loafing.

I could take this responsibility on if you like.  I'm terribly inexperienced
with the autotools stuff, but this would force me to learn it better and
cabal too.  Plus, I have to start somewhere and I think I want to be a darcs
maintainer some day.  I think I've learned enough about the core that if I
can rely on you and the other seasoned darcs devs for help that I could do a
better job than having no little or no regular maintenance.


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


I can't argue with that.


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


I wonder if this should be a feature request sent to the cabal devs and you
could work with them to support this?  Again, I just don't like the idea of
starting over.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-devel/attachments/20080416/805d3bcc/attachment.htm