Isaac Jones wrote:

Duncan Coutts writes:

...

On Fri, 2006-09-15 at 10:06 -0700, Isaac Jones wrote:

...

Emailing to libraries@, please followup to cabal-devel.

Here's a patch from Sigbjorn which adds --ghc-pkg-config-file= to cabal. This is an oldish patch, but I haven't stopped getting requests for this feature :)

This allows you to create a "local" package config file, rather than using the --user or --global files, this is useful for in-place building, as when you're developing a set of related packages.

I still have some debate about whether this patch should go in; it assumes a model of package registration where you have a config file (as opposed to a directory) which isn't the case for nhc or Hugs. But the idea doesn't seem to bother anyone but me, and the flag is clearly marked as a ghc-related flag, so I'm thinking of letting it through. Opinions?

Note that there is already a register --inplace flag to register a package in the build tree.

And this is mostly so you can build in the build tree, register to --user (or global), muck around a bit, and presumably unregister the package later.

...

To allow multiple packages to be built against each other inplace we'd also need some flag for configure.

To specify the package file location, you mean?

I guess you could do something sloppy like:

cd my-package ./setup build ./setup register --inplace --user

cd my-other-package ./setup configure --user etc

ghc-pkg unregister my-package --user

(which is what I just did for cabal & cabal-install.)

...

Would this be enough? Do we really also need the ability to specify arbitrary package databases? What is the use case?

I think it's mainly for registering packages together in a build tree.

I imagine that the "local package database" idea would be what cabal-install uses when it builds multiple packages. Remember our discussion a while back about a developer working on a multi-package system? You want a way to build all the packages in dependency order, but without installing. Some way to specify a local package database is the missing piece to make this doable. We don't have to assume the package database is a file: as far as Cabal is concerned, the package database is just a FilePath that it passes to hc-pkg when it needs to modify the database in some way. If we can assume that a database can always be specified by a FilePath, then this is compiler-independent (except that perhaps we want an 'hc-pkg init' command, which we don't currently have). BTW, I think that this part of Sigbjorn's patch might be already addressed in current Cabal: - better handling of package-specific header files during installation. If you use the Include-Dirs: and Includes: fields in your .cabal file to refer to package-local header files and directories, these will be created&copied during 'install' Cheers, Simon