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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
