<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Oct 17, 2008 at 10:19 AM, David Roundy <span dir="ltr">&lt;<a href="mailto:daveroundy@gmail.com">daveroundy@gmail.com</a>&gt;</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 &lt;<a href="mailto:dons@galois.com">dons@galois.com</a>&gt; wrote:<br>
&gt; daveroundy:<br>
&gt;&gt; On Thu, Oct 16, 2008 at 2:25 PM, Jason Dagit &lt;<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>&gt; wrote:<br>
&gt;&gt; &gt; * Now it seems as though the plan is to throw autotools out the window on<br>
&gt;&gt; &gt; all platforms and unconditionally. &nbsp;Meaning that on POSIX platforms we are<br>
&gt;&gt; &gt; changing something that isn&#39;t broken.<br>
&gt;&gt;<br>
&gt;&gt; No, the configure script *is* broken, it&#39;s just not as broken as cabal<br>
&gt;&gt; is. &nbsp;It doesn&#39;t allow very good forward-compatibility, only<br>
&gt;&gt; backward-compatibility, meaning with every major release of ghc, darcs<br>
&gt;&gt; is broke, because the configure script needs to explicitly &nbsp;mention<br>
&gt;&gt; every possible &nbsp;package that might contain a module that &nbsp;we use.<br>
&gt;&gt; Franchise fixes this bug.<br>
&gt;<br>
&gt; Could you summarise how cabal is broken?<br>
&gt; Given that we build and distribute aroun 800 packages using Cabal now,<br>
&gt; it&#39;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>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt;&gt; &gt; has been under development for a few years and is now approaching a mature<br><div class="Ih2E3d">
&gt;&gt; &gt; status. &nbsp;Cabal is tested, battle hardened, and all of hackage is built<br>
&gt;&gt; &gt; regularly to ensure that it remains working as new features are added and<br>
&gt;&gt; &gt; code is refactored. &nbsp;Duncan is very responsive about bugs, there are summer<br>
&gt;&gt; &gt; of code projects every summer for Cabal, it has a nice project website with<br>
&gt;&gt; &gt; bugtracker and community, lots of documentation, tutorials around the net,<br>
&gt;&gt; &gt; and otherwise seems very healthy and alive. &nbsp;Recently Duncan gave a talk<br>
&gt;&gt; &gt; about the future of Cabal[1] that sounds very promising.<br>
&gt;&gt;<br>
&gt;&gt; But as I&#39;ve mentioned many times, cabal doesn&#39;t even attempt to<br>
&gt;&gt; replace autotools. &nbsp;Given that I feel &nbsp;(and windows-concerned users<br>
&gt;&gt; such as Zooko agree) that a configure that tests for the presence of<br>
&gt;&gt; libraries is importent, cabal is simply not an option. &nbsp;Add &nbsp;with that<br>
&gt;&gt; a complete lack of forward or backward compatibility, and you&#39;ve got a<br>
&gt;&gt; tool that is really not a build system I would consider considering.<br>
&gt;<br>
&gt; Cabal implements extensive forward and backward compatibility support.<br>
&gt; Somehow hackage keeps building, as new compilers appear, and new<br>
&gt; libraries appear, and yet we don&#39;t need to update 800 .cabal files.<br>
&gt;<br>
&gt; 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. &nbsp;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&#39;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. &nbsp;Cabal has historically explicitly violated this with every<br>
major ghc release since it has existed. &nbsp;Perhaps you&#39;ll say that next<br>
time this won&#39;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. &nbsp;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&#39;m trying to understand this.&nbsp; 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?&nbsp; I think in practice it&#39;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. &nbsp;It doesn&#39;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>
&nbsp;It&#39;s a problem, of course, that ghc --make also solves, except that<br>
ghc --make doesn&#39;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&#39;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 &#39;configure&#39; 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.&nbsp; Perhaps even using the code in darcs&#39; setup.hs.<br>
<br>To me it sounds like an entire project has been established just to meet the need of darcs&#39; setup.hs.&nbsp; Maybe what I said sounds harsh, but it&#39;s not meant to.&nbsp; I just don&#39;t understand where the cost/benefit is at in this pursuit.<br>
<br>Jason <br></div>

</div></div>