[darcs-users] enfranchising darcs?

David Roundy daveroundy at gmail.com
Fri Oct 17 14:03:40 UTC 2008


On Thu, Oct 16, 2008 at 12:24 PM, Eric Kow <kowey at darcs.net> wrote:
> 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?

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

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

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

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

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

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.

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

It's not possible to make cabal's dependencies precise, so I'd
recommend limiting the amount of effort that goes into creating cabal
files.

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

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.

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

David


More information about the darcs-users mailing list