On 21 November 2004 01:15, Isaac Jones wrote:
> I would like to make a few interface changes to Cabal, but I want to
> get some feedback first, and to give a heads-up.
>
> By "target" I mean "place where the package will end up getting
> installed" rather than the build machine, which may be different.
>
> -= New commands =-
>
> ./setup copy (similar to ./setup install, with or without a
> prefix. Never runs register or postinst)
> ./setup test (runs a user-supplied IO () function)
> ./setup postinst (guaranteed to run on the target after register, runs
> a user-supplied IO () function)
>
> -= Changes to existing commands =-
>
> ./setup install now will not have the --install-prefix flag. Use
> "copy" instead. Install will always run register and postinst.
>
> ./setup register may or may not run on the target machine
This all looks good to me.
> -= Changes to package description file =-
>
> I can imagine a cabal package (wxhaskell) which has more than one
> "haskell package" / library in a single source tree.
>
> We might like to have more than one "haskell package" per "cabal
> package". That is, installing a single cabal package, Foo, might make
> "-package bar -package bang" available to the compilers.
>
> So I propose that we add the ability to have multiple libraries, just
> as we can currently do multiple executables.
>
> Right now, there's no great way to do this, besides perhaps having
> multiple directories with multiple Setup.lhs files. The downside to
> this is that it might make the description file a little more complex,
> though in the simple case, it won't change much. What do folks think?
First of all, I should say that I doing see an urgent need for this.
Packaging systems such as Debian, *BSD & Gentoo manage dependencies and
can build multiple packages in the right order just fine, and have
support for "collection" packages (eg. installing "kde" causes a bunch
of sub-packages to be installed). Introducing this functionality in
Cabal would be redundant on these systems. My feeling has always been
that we shouldn't duplicate functinoality that is available in a good
package system.
Given that, if you really want to do this, then here are my thoughts:
basically it would mean introducing another "layer" of packaging, albeit
one that lives only at the Cabal level, which Haskell compilers know
nothing of.
Here are some issues that initially spring to mind:
- Packages in this layer should be called something other than
packages, to avoid confusion (I'll call them shipments, for now).
- Should the shipment have a name of its own?
- Should it have a version?
- Presumably the packages in a shipment depend on each other. That
means we need to "temporarily" install packages so we can build
against
them. This isn't something that the current package proposal really
supports, but I think it would be useful.
Cheers,
Simon
