On Tue, Oct 14, 2008 at 08:41:16AM +0100, Eric Kow wrote: > Hey David, Hi Eric!
> You mentioned on the mailing list that you would like to remove autoconf > support within a few weeks and switch to the new franchise-based build > system. > > As I understand the situation: the plan is to start by replacing > autoconf and move to replacing the makefile as setup.hs becomes more > sophisticated. 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. > I think quite a few of us are concerned because this is potentially big > change, at least from the perspective of somebody who is trying to > build darcs. So it's probably a good idea for us to get our facts > together so that everybody is on board. > > 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 parallel build is nice, but it's not a reason to switch, since we've already got that with the makefile. 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. Another benefit is that in franchise there's less work keeping track of packages and modules than there was with our makefile. We no longer need to tell the build system which files need compiling, or which modules we use, since franchise can track down dependencies. This is nicer than our old Makefile (which actually could have been made to do the same). There's always trouble with each new ghc release, since APIs change and modules are moved from one package to another, but franchise knows how to search for modules in new packages, so for modules that just move from one package to another, changes to the build system (or franchise) will only be needed in order to improve error messages, not to make darcs compile. Oh, another side benefit of the switch is that franchise tests (e.g. looking for libz, libcurl, etc) all use ghc to do the testing rather than gcc, which means that unlike the existing autoconf tests, they will not give incorrect answers if the gcc in your path differs from the one that ghc uses (as typically happens when running under cygwin on windows). > 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. Another disadvantage is that it will make it hard for haskell-averse contributors to work on your build system. But that is moderated by the fact that we've had plenty of haskell hackers refuse to touch the autoconf-based build system. > 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. Yes, we just teach setup.hs a few more tricks, and then we can eliminate the use of configure.ac. During this process, I expect that the darcs-unstable and franchise repositories will remain tightly coupled, as the franchise API is definitely in flux, and I expect it'll change in response to darcs' needs. After eliminating the use of autoconf, there won't be an urgent need to stop using make, but I would like to do so eventually, as it will allow us to run on purely native windows (without either msys or cygwin). Actually, running the tests on native windows will involve coming up with an alternative to bash, and I've been thinking that it would be great to have a very simple shell in Haskell, just smart enough to run the existing .sh test scripts. This would also make it easier to keep the tests portable (since we could make pwd, grep, etc be build-in commands). At first, we'd have make call setup.hs to do some of its build tasks, then we'd later turn things around, to have setup.hs call make to do things it hasn't yet been taught about, and eventually we could remove the use of make altogether. > 4. What are your plans for developing and maintaining franchise? Do > you think you will be able to get it to point you would consider > stable fairly quickly? I think franchise is pretty stable already, and expect that it will be able to remain pretty stable once we've got it in the condision where we're content with it. It still should be taught a few tricks, like looking for .hsc files when searching for dependencies, but once that is done, I expect that franchise will remain essentially static. I hope to release a franchise 1.0 with a stable API concurrently with the first release of a darcs that uses franchise in its build system. > 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. David P.S. It doesn't show up in any of your questions, but I thought I should explain that franchise is designed to have minimal dependencies (the process package and the directory package) so that it should always be easier to install than darcs. In this respect, it's designed to be like an autoconf configure script, which itself has no dependencies (beyond a basic sh), but can detect and report on all the dependencies of an application. 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.
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
