[darcs-users] enfranchising darcs?

David Roundy daveroundy at gmail.com
Fri Oct 17 17:19:01 UTC 2008


On Fri, Oct 17, 2008 at 12:24 PM, Don Stewart <dons at galois.com> wrote:
> daveroundy:
>> On Thu, Oct 16, 2008 at 2:25 PM, Jason Dagit <dagit at codersbase.com> wrote:
>> > * Now it seems as though the plan is to throw autotools out the window on
>> > all platforms and unconditionally.  Meaning that on POSIX platforms we are
>> > changing something that isn't broken.
>>
>> No, the configure script *is* broken, it's just not as broken as cabal
>> is.  It doesn't allow very good forward-compatibility, only
>> backward-compatibility, meaning with every major release of ghc, darcs
>> is broke, because the configure script needs to explicitly  mention
>> every possible  package that might contain a module that  we use.
>> Franchise fixes this bug.
>
> Could you summarise how cabal is broken?
> Given that we build and distribute aroun 800 packages using Cabal now,
> it's hard to imagine that it is horribly broken.

It requires that you know in advance the packages that are required to
build a given project.

>> > has been under development for a few years and is now approaching a mature
>> > status.  Cabal is tested, battle hardened, and all of hackage is built
>> > regularly to ensure that it remains working as new features are added and
>> > code is refactored.  Duncan is very responsive about bugs, there are summer
>> > of code projects every summer for Cabal, it has a nice project website with
>> > bugtracker and community, lots of documentation, tutorials around the net,
>> > and otherwise seems very healthy and alive.  Recently Duncan gave a talk
>> > about the future of Cabal[1] that sounds very promising.
>>
>> But as I've mentioned many times, cabal doesn't even attempt to
>> replace autotools.  Given that I feel  (and windows-concerned users
>> such as Zooko agree) that a configure that tests for the presence of
>> libraries is importent, cabal is simply not an option.  Add  with that
>> a complete lack of forward or backward compatibility, and you've got a
>> tool that is really not a build system I would consider considering.
>
> Cabal implements extensive forward and backward compatibility support.
> Somehow hackage keeps building, as new compilers appear, and new
> libraries appear, and yet we don't need to update 800 .cabal files.
>
> Could you be more specific?

Cabal itself may be forward and backwards compatible, but applications
that use it are not, they are quite tightly coupled to the version of
cabal they were written for, and the versions of the compiler they
were written for.  When a new ghc major release is put out, most cabal
files need to be rewritten, and often in such a way that they won't
work with older versions of cabal.

I define backwards compatibility as meaning that the build
dependencies of darcs should not change with new releases of darcs,
until we make an explicit decision to abandon a particular older
configuration, and this choice should never be forced by the build
system.  Cabal has historically explicitly violated this with every
major ghc release since it has existed.  Perhaps you'll say that next
time this won't happen? I prefer to look at past track record.

I define forwards compatibility as meaning that provided the darcs
source code will compile with a future version of ghc, darcs will
continue to compile without modification to the build system or source
code.  Both the current autoconf system and the cabal system fail at
forwards compatibility in the common case where modules move from one
package to another or a package is renamed, since both of them rely on
knowing in advance the possible package names corresponding to given
modules.

David


More information about the darcs-users mailing list