Ian Lynagh wrote:
On Fri, Jun 15, 2007 at 03:06:07PM +0200, Thomas Schilling wrote:
On 15 jun 2007, at 14.09, Neil Mitchell wrote:
this being common practice, and yet permit it occasionally.
One thing I would like is given a package _data, which provides a data type, and a package _class which provides a class and various instances, I'd like to write in the _class cabal file:
#if has _data module Class.InstanceForData #endif
Perhaps configurations can support that?
This has the same problem, in that different versions of the same package provide different things.
Also, if you install _class first and _data second then you don't get Class.InstanceForData, whereas installing them the other way round you do.
Of course in this case we'd need to add some flags to the version number, to indicate, that tho installed version has a certain feature enabled.
This could be solved with a different package name of course, but I think it should be easy to add tags to a package version number:
if flag(debug) { build-depends: hunit ghc-options: -DDEBUG tag: debug exposed-modules: Demo.Internal }
One thing I have considered proposing is rather than just
exposed-modules: ... other-modules: ...
we could have (I'm not particularly advocating this syntax):
modules: ... modules[testing]: ... modules[internal]: ...
A simpler way to solve this problem is to have two packages, with the first package (foo-internal) exporting all the modules, and the second (foo) re-exposing just the non-internal modules. We don't currently have support for re-exposing, but it has lots of uses and it shouldn't be too hard to add (to GHC, at least). Perhaps it's not quite as nice, though: the foo-internal package shows up in your ghc-pkg list, and you need two separate Cabal packages (although good support for working with multiple packages is something we should have too). Cheers, Simon