<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Oct 17, 2008 at 10:19 AM, David Roundy <span dir="ltr"><<a href="mailto:daveroundy@gmail.com">daveroundy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Oct 17, 2008 at 12:24 PM, Don Stewart <<a href="mailto:dons@galois.com">dons@galois.com</a>> wrote:<br>
> daveroundy:<br>
>> On Thu, Oct 16, 2008 at 2:25 PM, Jason Dagit <<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>> wrote:<br>
>> > * Now it seems as though the plan is to throw autotools out the window on<br>
>> > all platforms and unconditionally. Meaning that on POSIX platforms we are<br>
>> > changing something that isn't broken.<br>
>><br>
>> No, the configure script *is* broken, it's just not as broken as cabal<br>
>> is. It doesn't allow very good forward-compatibility, only<br>
>> backward-compatibility, meaning with every major release of ghc, darcs<br>
>> is broke, because the configure script needs to explicitly mention<br>
>> every possible package that might contain a module that we use.<br>
>> Franchise fixes this bug.<br>
><br>
> Could you summarise how cabal is broken?<br>
> Given that we build and distribute aroun 800 packages using Cabal now,<br>
> it's hard to imagine that it is horribly broken.<br>
<br>
</div>It requires that you know in advance the packages that are required to<br>
build a given project.</blockquote><div><br>What will Franchise do when two different packages provide overlapping modules?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> > has been under development for a few years and is now approaching a mature<br><div class="Ih2E3d">
>> > status. Cabal is tested, battle hardened, and all of hackage is built<br>
>> > regularly to ensure that it remains working as new features are added and<br>
>> > code is refactored. Duncan is very responsive about bugs, there are summer<br>
>> > of code projects every summer for Cabal, it has a nice project website with<br>
>> > bugtracker and community, lots of documentation, tutorials around the net,<br>
>> > and otherwise seems very healthy and alive. Recently Duncan gave a talk<br>
>> > about the future of Cabal[1] that sounds very promising.<br>
>><br>
>> But as I've mentioned many times, cabal doesn't even attempt to<br>
>> replace autotools. Given that I feel (and windows-concerned users<br>
>> such as Zooko agree) that a configure that tests for the presence of<br>
>> libraries is importent, cabal is simply not an option. Add with that<br>
>> a complete lack of forward or backward compatibility, and you've got a<br>
>> tool that is really not a build system I would consider considering.<br>
><br>
> Cabal implements extensive forward and backward compatibility support.<br>
> Somehow hackage keeps building, as new compilers appear, and new<br>
> libraries appear, and yet we don't need to update 800 .cabal files.<br>
><br>
> Could you be more specific?<br>
<br>
</div>Cabal itself may be forward and backwards compatible, but applications<br>
that use it are not, they are quite tightly coupled to the version of<br>
cabal they were written for, and the versions of the compiler they<br>
were written for. When a new ghc major release is put out, most cabal<br>
files need to be rewritten, and often in such a way that they won't<br>
work with older versions of cabal.<br>
<br>
I define backwards compatibility as meaning that the build<br>
dependencies of darcs should not change with new releases of darcs,<br>
until we make an explicit decision to abandon a particular older<br>
configuration, and this choice should never be forced by the build<br>
system. Cabal has historically explicitly violated this with every<br>
major ghc release since it has existed. Perhaps you'll say that next<br>
time this won't happen? I prefer to look at past track record.<br>
<br>
I define forwards compatibility as meaning that provided the darcs<br>
source code will compile with a future version of ghc, darcs will<br>
continue to compile without modification to the build system or source<br>
code. Both the current autoconf system and the cabal system fail at<br>
forwards compatibility in the common case where modules move from one<br>
package to another or a package is renamed, since both of them rely on<br>
knowing in advance the possible package names corresponding to given<br>
modules.</blockquote><div><br>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?<br>
<br>Merging replies David said:<br></div></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">The darcs setup.hs script demonstrates this. It doesn't mention what<br>
packages are needed to build darcs, but franchise determines this,<br>
which means that if a package name is changed, darcs will still build.<br>
It's a problem, of course, that ghc --make also solves, except that<br>
ghc --make doesn't solve other problems like defining environment<br>
variables based on the presence of certain modules or external<br>
libraries.</blockquote><div><br>And Don said this in a different email:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Ah ha. Then the important thing here is that Cabal doesn't do C or<br>
system tests (though this is an open ticket). If someone has some nice<br>
Haskell code that could do that, Cabal could actually use it, to<br>
replace autotools.<br><br>
After all, Cabal will run whatever 'configure' script there is, written<br>
in whatever language.<br><br>
An opening for a new, better feature test system there perhaps, leaving<br>
cabal to deal with language flags and distribution. </blockquote><div><br>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.<br>
<br>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.<br>
<br>Jason <br></div>
</div></div>