cabal design

[Frederik Eaton]

Hi, 

First of all I want to thank Isaac Jones for his work on Cabal.

There are a few issues I would like to raise.

1) Cabal files can have different names, yet only one can exist in a
directory. I've been told that the reason for the former is that Isaac
wants to support building multiple packages in a directory, but
currently the feature isn't implemented, so only one cabal file is
allowed.

Certainly, it would be a nice feature, but more importantly it seems
that it would require some API changes or additions which should be
made sooner rather than later. Is there a document describing how it
would work? Is there a roadmap, a schedule for implementation?

2) As I have pointed out earlier, some aspects of the 'cabal'
installation are specified at configure time, others (whether the
package is --user or --global) must be specified at install time. In
effect this means that the configuration is spread out over multiple
commands, which is rather unsavory.

3) The way that a 'cabal' package with a 'configure' script should be
built is not easy to determine. There are some very useful programs
(http://toastball.net/toast/) which build and manage packages of all
kinds automatically, by running 'configure' with a local prefix, etc.
How should these tools be extended to work with 'cabal' packages? With
some 'cabal' packages, the user is supposed to run 'configure' first,
and then 'runhaskell Setup.hs'. With other 'cabal' packages, the user
is supposed to just run 'runhaskell Setup.hs', and this will run
'configure' automatically. Is there a right way? Is there a way to
distinguish the two types of packages automatically?

4) Cabal's inability to let users specify package.conf-s other than
the user or global package.conf, and ghc's refusal (and that of other
compilers) to let users specify paths for things via environment
variables, not only complicates the task of tools like 'toast' (above)
but makes it hard to create a "test" or otherwise isolated
installation of a library or other package. For C libraries all I have
to do is add, e.g., $HOME/.toast/armed/include to CPATH and everything
works - whereas all of my haskell libraries would have to share the
same user package.conf in order for using them to be manageable. To be
sure, environment variables are not entirely necessary to do this, the
relevant values could be explicitly passed between each stage of a
build, but environment variables make the task much simpler. In any
case, functional programming is about modularity. We should ask our
compilers and packaging tools to support modularity as much as
possible as well. To lag behind 'gcc' and 'autoconf' is not
acceptable.

5) It seems that there should be a way to build multiple packages
which depend on each other, in such a way as that the first package
doesn't have to be installed for the second package to be built. In
other words, perhaps something like a dummy installation as in #4 is
called for. I have seen mention that support for building multiple
packages is planned, but how? When? What stage of implementation are
we in?

6) I think it should be easy to use 'cabal' for development; however,
when I am building a package with multiple executables, every 'build'
seems to re-link each executable, regardless of whether it needs
re-linking or not, which is quite slow. Maybe this is a bug in ghc,
but it would be good to fix it or work around it. In the same vein, it
would be nice to have a standard command that invokes "runhaskell
Setup.hs" but with fewer keystrokes.


I'm not sure how much of this Isaac has planned out on his own and is
busy implementing, vs. how much is waiting for someone to write a
design document for. I probably don't have time to do much work on
implementation, but I could be willing to, say, start a page on the
wiki outlining what I think is involved, what the API should look
like, etc., if this has not been done yet.

Regards,

Frederik