<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Oct 18, 2008 at 6:02 AM, Eric Kow <span dir="ltr"><<a href="mailto:eric.kow@gmail.com">eric.kow@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;">
It seems we all agree that /some/ form of Cabalisation is a good thing to have<br>
in the official darcs repository. This is what I believe to be the form of<br>
cabalisation that everybody can live with.</blockquote><div><br>Cool. It's good to be talking about these on the public mailing list.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With these patches, cabal configure and cabal build configure and build darcs<br>
respectively using franchise as the build method. This allows us to use<br>
franchise's checking for C libraries, while providing metadata to integrate with<br>
cabal-install and to help automatic distro packaging tools. The package<br>
dependency information is on a purely advisory basis; it is ignored by franchise.</blockquote><div><br>Which library does the installation? If cabal is the one taking the risk of screwing up my system that makes me feel a lot better about running install. I'd also prefer if we could get cabal doing the build, if only because cabal has the nice feature of not cluttering src/ with intermediate files. Maybe franchise has the feature and it's turned off by default? <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Notes<br>
-----<br>
* Dependency information is ignored, and is provided on a purely advisory basis<br>
only</blockquote><div><br>Hmm...then how is it calculated? I guess I'll have to try it out to see. In particular ambiguity and conflict resolution between packages may be an issue. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* I disabled building the documentation for now because I would find setup<br>
hanging (?) on a pdfetex step</blockquote><div><br>Obviously you were busy with the rest of this, but have you had a chance to mention this to Duncan or put a bug in the cabal bug tracker? Or is this a franchise bug? I'm not sure, other than emailing David directly where you would report a bug for the latter.<br>
<br>If we're going to be serious about pushing franchise on people then we need to get serious about making a community website for it so that bug reports, feature requests, and user questions have an obvious place to go.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* I left the Cabal setup script (as Setup-cabal.lhs) because I think there is<br>
some functionality we ought to use from it.</blockquote><div><br>Ah, so I could still build with cabal just by renaming locally. That's handy. I don't have franchise installed.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Unfortunately, cabal-install passes the -i flag to ghc, with no arguments,<br>
when building setup.hs. This means that getting a Distribution.Darcs module<br>
to work with cabal-install may be tricky. It's not essential, but it could<br>
have kept the franchise setup.hs tidy, and also facilitated sharing with the<br>
parallel Cabalisation effort</blockquote><div><br>Looking here: <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#search-path">http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#search-path</a><br>
It looks like -i resets the search path during compilation. So are you saying, it's hard to have uninstalled code be part of Setup.hs unless it's actually at the same directory level or inside of Setup.hs? <br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The cabalisation branch version controls the Autoconf.lhs and parameterises<br>
it with flags. This seems to be a nice alternative to regenerating it.<br>
Perhaps we could adapt setup.hs accordingly?</blockquote><div><br>Franchise seems to use a template system. File names that end in ".in" are in some sort of template language. If you look in setup.hs you'll see things like, createFile "foo". Unlike the name and type suggest createFile isn't equivalent to the command 'touch'. It's actually going through all the user defined substititions (called replacements), and instantiating a template based on them. Someone should rename 'createFile' to something that says, 'creates file 'foo' from a template named '<a href="http://foo.in">foo.in</a>' by looking at globally defined replacements'. I'd say, instantiateFromTemplate, would be a significantly better name. Also by changing the type so that it takes the template name and the output file name it would be more clear what it does.<br>
<br>Which is another problem I had. Trying to understand what setup.hs does has been difficult. I had to read the entire source of Franchise twice before I could figure out any part of what setup.hs is doing, and I still don't know how to extend setup.hs. The heavy use of operators and redefined Haskell98 functions made the source hard for me to read[1]. Only one module, Util.hs, seems to have any source level documentation. But, all that aside, the really hard to grok part is the undocumented mutually recursive datastructures that sit at the heart of franchise. Unfortunately, as a user of setup.hs you need to understand them because they are exposed at that level currently. I forget what the types are called but it's the ones that use (:<), (:<-), and (|<-) as constructors. You can see them at use in setup.hs. The impression given there is that they hide some sort of magic.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The patches mostly come from Petr and Ganesh's cabalisation branch. It's missing<br>
their Workaround stuff, and has a couple of very minor changes from my end.</blockquote><div><br>Could you please comment on the implications of "missing their Workaround stuff"? I have used mornfall's version of these changes quite successfully to build darcs sans makefile, so I'm curious. I'm not sure if I should keep working from mornfall's repo or go with stable + this bundle.<br>
</div></div><br>Thanks Eric!<br>Jason<br><br>[1] endsWith/beginsWith/startsWith all seem to be equivalent to functions found in the Haskell98 report. By giving new definitions of these functions I was tricked into reading their definitions and trying to understand *how* they differ in behavior from the isSuffixOf and isPrefixOf. I have patches that replace the home grown versions with the ones from Data.List if anyone wants them.<br>
</div>