[darcs-users] enfranchising darcs?

[Jason Dagit]

On Fri, Oct 17, 2008 at 10:19 AM, David Roundy <daveroundy at gmail.com> wrote:

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


What will Franchise do when two different packages provide overlapping
modules?


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


I'm trying to understand this.  The argument about back and forward
compatibility is justifying making a new configure and build system from
scratch to avoid tweaking a configuration every few months?  I think in
practice it's once or twice a year?

Merging replies David said:

> The darcs setup.hs script demonstrates this.  It doesn't mention what
> packages are needed to build darcs, but franchise determines this,
> which means that if a package name is changed, darcs will still build.
>  It's a problem, of course, that ghc --make also solves, except that
> ghc --make doesn't solve other problems like defining environment
> variables based on the presence of certain modules or external
> libraries.


And Don said this in a different email:

> Ah ha. Then the important thing here is that Cabal doesn't do C or
> system tests (though this is an open ticket). If someone has some nice
> Haskell code that could do that, Cabal could actually use it, to
> replace autotools.
>
> After all, Cabal will run whatever 'configure' script there is, written
> in whatever language.
>
> An opening for a new, better feature test system there perhaps, leaving
> cabal to deal with language flags and distribution.


>From a possibly naive point of view, it sounds like we could use Cabal just
fine if we wrote an appropriate Setup.lhs or configure.hs.  Perhaps even
using the code in darcs' setup.hs.

To me it sounds like an entire project has been established just to meet the
need of darcs' setup.hs.  Maybe what I said sounds harsh, but it's not meant
to.  I just don't understand where the cost/benefit is at in this pursuit.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20081017/e59205ec/attachment-0001.htm