[darcs-users] enfranchising darcs?

David Roundy droundy at darcs.net
Tue Oct 14 15:23:47 UTC 2008


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20081014/fcdb5ce4/attachment-0001.pgp 


More information about the darcs-users mailing list