[darcs-users] enfranchising darcs?

Thu Oct 16 16:24:47 UTC 2008

Thanks, David!  Those extra details are quite helpful.

When I went to AngloHaskell this year, I got a chance to meet Neil
Mitchell and ask him a very simple question:                                                                                            

  How I do get more Windows developers hacking on Haskell?                                                                              

The advice that Neil gave me can be boiled down to this:                                                                                

  Darcs needs to be easier to build   

So I think it is definitely encouraging to see us move towards a less
Unix-oriented build system of some sort.  I know there is a bit of
disagreement on this, but to keep things healthy constructive, I think
we should all keep this core goal in mind.  Also, if you are following
this thread, you may find it useful to read the following wishlist for
background:

  http://wiki.darcs.net/index.html/CabalWishlist

On Tue, Oct 14, 2008 at 11:23:47 -0400, David Roundy wrote:
> That's right.  I think it won't be long before we can remove the use
> of autoconf.  It's just a matter of translating the remaining
> configure stuff into franchise, which won't take nearly as long as it
> might seem, since much of the contents of configure.ac will no longer
> be needed.

One option we could consider is to pare configure.ac down to what we
consider to the be minimum.  Maybe having some sort of assurance that
setup.hs and configure.ac do the same thing would be useful.

> > 1. What are the main benefits behind this switch?  Simplifying the
> >    Windows build certainly sounds like an interesting one.  Are there
> >    any franchise features you think make this particularly worthwhile?
> >    Parallel builds sounds like a nice one.

> The biggest benefit of the switch is that it will make it far easier
> to compile darcs for windows.  In fact, it's easy enough that I can
> now compile a windows binary using wine on my ubuntu machine.  Being
> able to build darcs without involving autoconf (or GNU make) is a very
> good thing.

Sounds good.  Anybody on Windows tried this yet?  It's still in
http://darcs.net/unstable at the moment

> > 2. What are the risks involved?  Are there any potential pitfalls to
> >    be looking out for?  How can we be confident that it would be safe
> >    for us to make this switch?
> 
> Well, the risk is primarily that franchise won't work, right? But it
> won't be hard to switch back, and we've got time before the next
> release is planned.

Anybody else have concerns about where an autoconf to franchise switch
could go wrong?

> > 3. What are your rollout plans?  What are the criteria for deciding
> >    that it would be the right time to make the switch?  Is it just a
> >    matter of teaching setup.hs to do more tricks, or are there
> >    things that need to change in the universe as well.

I have thought of some items for my personal wishlist

First: pre-requisites checking for more modules like Control.Monad.Error
and Text.ParserCombinators.Parsec.  Franchise automatically detects the
dependencies, which is nice.  But at our current configuration it does
not warn users if they are missing them.  This is just a matter of
extending setup.hs with more module requirements.  Could franchise help
us to write setup.hs by telling us what module requirements we would
need to add?  Ian has provided a list of boot packages for GHC 6.8 here:
  http://darcs.haskell.org/ghc-6.8/ghc/libraries/boot-packages
Presumably, any module which is not provided by darcs or by one of the
boot packages should be listed as a requirement?

Second: Another item would be to ensure that the build process is at
least familiar to Haskellers, i.e. that it resemble Cabal-style builds
and offer the common switches.  I see that we have switches --libdir and
--docdir, which seems nice.

Third: GHC 6.10 compatibility

> > 5. Shall we be expecting people to install franchise separately, or
> >    will it be a part of darcs?
> 
> I expect developers will install franchise separately, and don't want
> to stick it into the darcs repository.  However, I anticipate teaching
> make dist (or its equivalent) to put franchise into the darcs tarball
> so users won't need to install it, just as we run autoconf so users
> won't need to have autoconf to build darcs.

Good, this will be helpful for hoop-avoidance.

> P.P.S. I should perhaps mention for the sake of cabal advocates:
> franchise is not living in the same ecosystem niche as cabal.  Cabal
> has never intended to replace the use of autoconf in configuring
> programs like darcs.  As it turns out, by the time we've replaced
> autoconf, it isn't hard to replace make as well.

If I understand correctly, both cabal and franchise offer package
building and prerequisite checking.  Other than that, Cabal offers
explicit package version metadata (which helps tools like cabal-install
and cabal2rpm) on the Cabal side, and automatic dependency detection
(which helps ensure that packages compile in new environments, say GHC
6.10) on the franchise side.

There are a lot of folks that would rather we just used Cabal.  After
all, it is the de facto Haskell standard and has been around for longer
(thus being potentially more battle-tested).  David strongly opposes
this move, I think, because he feels that mandatory metadata is a form
of redundancy (maintainence hassle) can also be fragile when, for
example, a new version of GHC comes along.

I hope there are ways for Cabal fans and franchise fans to work
together, maybe with Cabalisation as an effort in an unofficial branch.
There are also some shared problems that the cabalisations and
enfranchisement have in common and could work together on.  Ganesh's
zlib patches are one good example, as are David's Workaround
simplifications.  Some options we could consider:

1. Automatic cabal file generation.
   Franchise has the ability to generate a cabal file for use with
   package.  We do not currently use this feature, but maybe it would be
   useful to enable it?  It seems like franchise's cabal-file-generation
   would need to grow some hard-coded knowledge, for example, about the
   GHC 6.8 and 6.10 base splits.  If we need hand-written information,
   we could version control the cabal file and darcs revert whatever the
   automatic generation clobbers that we do not want.

2. Distribution.Darcs module. 
   Whether we use Cabal or Franchise, we need to have arbitrary Haskell
   code for darcs version detection, building the documentation.  Maybe
   we could facilitate sharing by using a Distribution.Darcs module to
   hold these fancy tricks.  This could be nice anyway for separating
   the fanciness from the core build.

3. Using franchise as the cabal build method.
   The Simple build method in cabal does not support parallel builds.
   Maybe until Cabal catches up -- there is work to make Cabal smarter
   -- we could use tell Cabal we are using a Custom build method, i.e.
   franchise.  This lets us take advantage of parallel building.  It
   also means that we would have explicit package dependencies on a
   purely advisory basis (if they are wrong, they break cabal-install
   or cabal2deb style tools).

Note that I am not really trying to push any of these options, just
pointing out that we should not get stuck on our disagreements.
Instead, it would be best if we could look out for ways to *make use*
of these disagreements to find ways of improving darcs.

Thanks, everybody!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20081016/ddedcc55/attachment.pgp 