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