Andrew Pimlott writes:

On Fri, Sep 15, 2006 at 10:06:55AM -0700, Isaac Jones wrote:

...

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.

I don't know anything about packages in nhc or Hugs, but if they use directories, isn't the obvious thing to interpret the "ghc-pkg-config-file" as the package directory?

nhc doesn't really work w/ cabal at all (or is it vice versa? ;) ) For Hugs, we can install in a local directory, but registering doesn't really have the same behavior in Hugs than it does in GHC. With GHC we have this level of indirection that help us to find packages. In GHC, I can say --prefix=~/, and after I register with --user or whatever, ghc can find that package. With Hugs, last I heard, Hugs will only find packages installed in standard places; it doesn't have that level of indirection. So in a sense, the package registration for Hugs still doesn't quite make sense, although I haven't really followed Hugs lately. Whether it will make even less sense if we try to impose some kind of "in-place" package config file? Maybe Ross can let us know if anything has changed. peace, isaac

On Sat, 2006-09-16 at 08:54 +0200, Duncan Coutts wrote:

Note that there is already a register --inplace flag to register a package in the build tree. To allow multiple packages to be built against each other inplace we'd also need some flag for configure.

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

(BTW, I'm not saying we don't need it, I'm just wondering what people want it for)

From discussion on #ghc:

JHC and indeed every impl except GHC have no concept of a package db. JHC for example would certainly be able to support using a package in-place in the build tree and indeed could support an isolated build environment (indeed it's probably easier with JHC than GHC). So the suggestion is that it is these concepts of using inplace, or having an isolated build environment that should be supported by cabal since they can be mapped to appropriate things in each impl, rather than adding --yhc-pkg-foo and --ghc-pkg-bar flags. I think this has been Isaac's approach generally, to target the things that people are trying to do, rather than just exposing every underlying mechanism which people currently use to accomplish those goals. Duncan

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