On Thu, Oct 16, 2008 at 12:24 PM, Eric Kow <[EMAIL PROTECTED]> 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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
