[darcs-users] darcs patch: Import cabalisation: Setup.lhs, darcs.ca... (and 13 more)

[Jason Dagit]

On Sat, Oct 18, 2008 at 6:02 AM, Eric Kow <eric.kow at gmail.com> wrote:

> It seems we all agree that /some/ form of Cabalisation is a good thing to
> have
> in the official darcs repository.  This is what I believe to be the form of
> cabalisation that everybody can live with.


Cool.  It's good to be talking about these on the public mailing list.


> With these patches, cabal configure and cabal build configure and build
> darcs
> respectively using franchise as the build method.  This allows us to use
> franchise's checking for C libraries, while providing metadata to integrate
> with
> cabal-install and to help automatic distro packaging tools.  The package
> dependency information is on a purely advisory basis; it is ignored by
> franchise.


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?

Notes
> -----
> * Dependency information is ignored, and is provided on a purely advisory
> basis
>  only


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.

* I disabled building the documentation for now because I would find setup
>  hanging (?) on a pdfetex step


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.

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.

* I left the Cabal setup script (as Setup-cabal.lhs) because I think there
> is
>  some functionality we ought to use from it.


Ah, so I could still build with cabal just by renaming locally.  That's
handy.  I don't have franchise installed.

* Unfortunately, cabal-install passes the -i flag to ghc, with no arguments,
>  when building setup.hs.  This means that getting a Distribution.Darcs
> module
>  to work with cabal-install may be tricky.   It's not essential, but it
> could
>  have kept the franchise setup.hs tidy, and also facilitated sharing with
> the
>  parallel Cabalisation effort


Looking here:
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#search-path
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?

* The cabalisation branch version controls the Autoconf.lhs and
> parameterises
>  it with flags.  This seems to be a nice alternative to regenerating it.
>  Perhaps we could adapt setup.hs accordingly?


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 'foo.in' 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.

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.

The patches mostly come from Petr and Ganesh's cabalisation branch.  It's
> missing
> their Workaround stuff, and has a couple of very minor changes from my end.


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.

Thanks Eric!
Jason

[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20081018/8cbbd490/attachment.htm