[darcs-users] enfranchising darcs?

Eric Kow kowey at darcs.net
Fri Oct 17 15:16:27 UTC 2008

Ok! So it looks like we're making some progress here in the sense
that a couple of things which may not have been clear to everyone
before are now much more apparant.

1. We now know for a fact that franchise really works on Windows
   and also on GHC 6.10

2. David is open to Cabalisation... just not as our build method

3. Even though we may have missed this the first time around, we
   now know that the key blocker for Cabal is that it can't do
   configure checks for non-Haskell dependencies.

On Fri, Oct 17, 2008 at 10:03:40 -0400, David Roundy wrote:
> I'm not sure what you mean by this.  Franchise does inform the user
> when a required package isn't present.  That's the main point of the
> configure stage.

Right, so what I had meant was that this is not an issue with franchise
itself, just that our particular setup.hs at the moment does not appear
to be aware that some packages (like mtl, or the module
Control.Monad.Error) are required.  Actually on second thought, I may
have been mistaken, in which case, I apologise for the noise.

The idea is that if I do:

  runhaskell setup clean
  ghc-pkg unregister mtl
  runhaskell setup configure
  runhaskell setup build

For some reason I thought the configure would pass and that the build 
would fail.  But I see this was an error, because actually the configure
fails with:

| Error building darcs.depend:
| src/Printer.lhs:58:7:
|     Could not find module `Control.Monad.Reader':
|       Use -v to see a list of the files searched for.
| Error:  Failure building darcs.depend
| src/Printer.lhs:58:7:
|     Could not find module `Control.Monad.Reader':
|       Use -v to see a list of the files searched for.

... which is more or less reasonable since it's configure that's
failing.  I would prefer something more informative, like "try
installing mtl", but as you say below...

> Franchise hasn't yet been taught to determine which
> package provides a given module, but this is information that should
> either be put into franchise itself or extracted from hackage directly
> (or perhaps a combination of the two?).

I was first imagining it being encoded in setup.hs just as we do in
configure.ac, but having some sort of more automated approach to
giving users advice might be nice.

> > Third: GHC 6.10 compatibility
> There's a user who's been working on ghc 6.10 compatibility, and
> franchise now builds and installs on ghc 6.10.

Cool! (and hello, Austin!)
> > 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.

Aside from the below, is this my summary for your position correct?
> As I said above, cabal doesn't offer configuration checks for anything
> but haskell packages, and that's a non-starter for darcs.  The cabal
> policy is to use autotools, and franchise is written primarily as a
> replacement for autotools.  The build system is just something that's
> easy to implement once we've got configuration checking down (since
> the configuration checking requires that we know how to do the build).

That indeed seems like a key factor.  I have updated the cabal wishlist

For what it's worth, I was worrying about this when talking to Neil
about Cabalisation, and his answer was to shift the work over to third
party Haskell bindings of libcurl and friends (this may involve some
work creating said bindings).  But I suppose the question still remains
those packages -- how to do configure checking for the underlying C
libraries without resorting to autoconf?

> Cabalization of darcs is like debianization of darcs or rpmization of
> darcs.  It's  a good idea, but should be independent of darcs' build
> system.

I urge Cabal fans to take note of this comment.  It's not cabalisation
of darcs that's being opposed, but relying on cabal for the build system.
> > 2. Distribution.Darcs module.
> Yeah, it's not a bad idea to move  some of this stuff into franchise
> itself.  But I'm not sure what sort of API would be most helpful to
> other programs.

Into franchise itself?  I was just thinking of something in the darcs
darcs repository.
> > 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).
> This does make sense.  Just as it previously made sense to use
> configure/make as the build system.  I'm not sure what you mean about
> explicit package dependencies.  cabal2deb is never going to be useful
> for darcs, since cabal doesn't support  non-haskell dependencies.
> Similarly cabal-install will give you nothing better than a very-slow
> darcs, unless you luck out and happen to have libcurl-dev  or
> libwww-dev already installed.

By explicit, what I really meant to say was 'explicit about package
version numbers'

So my goal is to push this discussion into some sort of rough consensus.
We don't all have to be thrilled with whatever decision we're making;
but we need to settle on something more or less acceptable (even with a
little grumbling).  What would be most helpful here are some proposals
from Cabal fans about how they would deal with the issue of non-Haskell
dependencies... if there are no such proposals, I think I will just
catch stable up with unstable completely.


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/20081017/437824c8/attachment.pgp 

More information about the darcs-users mailing list