Claus Reinke wrote:
It could be done using the tricks that Claus just posted and I
followed up on. You'd need a separate package for hsFoo-2 that
specifies exactly which bits of hsFoo-3 are re-exported. Given some
Cabal support and a little extension in GHC, this could be made
relatively painless for the library maintainer.
are those tricks necessary in this specific case? couldn't we
have a list/range of versions in the version: field, and let cabal
handle the details?
I don't understand what you're proposing here. Surely just writing
version: 1.0, 2.0
isn't enough - you need to say what the 1.0 and 2.0 APIs actually *are*,
and then wouldn't that require more syntax? I don't yet see a good reason
to do this in a single .cabal file instead of two separate packages. The
two-package way seems to require fewer extensions to Cabal.
aside: what happens if we try to combine two modules M and N
that use the same api A, but provided by two different packages
P1 and P2? say, M was built when P1 was still around, but when
N was built, P2 had replaced P1, still supporting A, but not necessarily
with the same internal representation as used in P1.
Not sure what you mean by "try to combine". A concrete example?
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
