cabal design

[Isaac Jones]

Duncan, Thanks for your detailed mail.  I don't think I have notes on
some of the solutions / workarounds / possibilities we had come up
with.  Would you mind following up with possible solutions and / or
workarounds?  Especially if you think they'll have an impact on the
--in-place idea.

Duncan Coutts <duncan.coutts at worcester.oxford.ac.uk> writes:

(snip)
> So ./setup register --in-place suggests that the library will be
> registered in it's current location, ie the build tree.
>
> So this would allow the library to be used in building other libraries
> or programs in the same "distributable".

Right.

> Or it would allow the library to be used without installing to its final
> location which might be useful in some circumstances (which I must admit
> are not obvious to me).

Just the above, I think.

> So this is a useful feature and we're happy to help out in implementing
> it.

:-)

> However what we the gentoo folk want is subutly different. We want to
> register into a package database other than the global or user one.
> However we want to register it for it's final installed location, not
> the current location in the build tree.

I see what you're saying... For instance, there will be a few paths in
that install file which will not correspond to the package's final
destination.  We could possibly control that with yet another flag to
tell it to register to the in-place database, but use the final
destination directories... Then you'd probably want some kind of
'combineDatabases' function that reads the list from one database and
cats it to the global database.  That's not too nice.

Maybe I'll just break down and give you some way to produce the
.installed-package-info reliably during build and you can feed it to
ghc-pkg.  That would give you what you want, right?

peace,

  isaac