cabal design

[Isaac Jones]

Frederik Eaton <frederik at a5.repetae.net> writes:

> 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?

I'm not so sure that the change is very big at all... it should just
be a matter of adding a feature to allow libraries to register
themselves "in-place" or something... then compute the dependencies
between the packages, build them in order, install the libraries
you'll need in-place, then compile the programs.

The problems come up where a package might need to actually be in the
install location in order to work.  Hopefully that's not too common.

> 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.

That's on the TODO list; I think that it makes sense to install a
package --user if it's configured w/ --user, but you'll still be able
to over-ride it with --global.  Pretty easy change.

> 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?

What packages require you to run configure by hand?  That is indeed
incorrect in the sense that it doesn't conform to the cabal interface.
If the packager is doing that in order to alter the .cabal file, then
that's a problem... the correct way to do this is covered in the
manual, and configure has built-in support in cabal.

> 4) Cabal's inability to let users specify package.conf-s other than
> the user or global package.conf

I think the gentoo guys were going to implement this for us; in any
case, it's a subset of 1).  This should be pretty easy; the only
question is whether we should have a --in-place or a
--package-conf=... Where in-place would choose a "standard" one
(./packages.conf or something).  The reason I'd prefer the former is
that not all systems _have_ an idea of a package.conf file, so
--package-conf= would make no sense for most compilers.  I try to
avoid that.  The reason for the later would be if there's some
use-case that --in-place does not work for.

> , and ghc's refusal (and that of other
> compilers) to let users specify paths for things via environment
> variables,
(snip)
> To lag behind 'gcc' and 'autoconf' is not acceptable.

GCC lets you specify things via environment variables?  I've never
seen that... if ghc were to adopt this kind of behavior, I hope it
wouldn't be the default; as in 'make', it should require an extra flag
like -e.

> 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? 

This is the same as 1.

> What stage of implementation are we in?

We're in the stage of "Isaac has been too busy writing papers and book
reviews and needs to get working."  I'm always happy to get patches,
though.

> 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. 

I'm not sure why ghc --make re-links executables every time.

For libraries, I think we could use support from ghc to tell whether
we need to re-link the library; ghc goes through and skips stuff that
doesn't need to get built, and then we link everything in the library;
if ghc could somehow let us know that nothing needed to get built,
that would be very helpful; otherwise, someone has to write the logic
to go through and check it all just like ghc does.  This code should
be out there somewhere.

> 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.

Folks should be putting #!runhaskell at the top and naming their
scripts Setup.lhs, then at least it's easier in Unix.  I've been
thinking about ways to solve this problem.

> 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. 

You're always welcome to submit patches and suggestions on how to do
stuff, and I and other folks here will be more than happy to engage
you.  I've been a little too distracted with other stuff, and keep
hoping that GHC 6.4.1 will appear so I can release cabal 6.2 and get
hacking on other stuff.  I should just make a 'stable' branch or
something.

Finally, thanks for all of your great suggestions.  We need feedback
from as many different users as possible.  We've spent a long time
guessing about what folks might need, and now that cabal is in the
wild, we're getting good feedback about what they actually need :)

peace,

  isaac