Thomas Schilling wrote:
On Sun, 2007-10-28 at 13:49 -0400, Isaac Dupree wrote:
Simon Marlow wrote:
Probably it could be made clearer. In 4.2 the idea is that instead of replacing
base-2.0 ==> base-3.0 + directory-1.0 + array-1.0 + ...
you would replace
base-2.0 ==> newbase-1.0 + directory-1.0 + array-1.0 + ...
and additionally have a package base-3.0 that re-exports the whole of (newbase + directory + array + ...). "Macros" in cabal: Why not just say that depending on base-3.0 actually means that you have to depend on newbase-1.0, and directory-1.0, etc... Why is compiler support needed? is it really possible that I still don't understand?
You'd still have the problem that every package has to specify this "macro" for itself. You'd want some global macro-database to avoid this. The better solution would be to just have a package that re-exports everything. I.e., the definition of package base-2.0 would look something like this:
if has system has base-3.0, directory, array ... re-export else exposed-modules: Data.Maybe, Data.List, ...
Of course it would be defined in the same place that base-3.0 would normally be defined if it existed (hypothetically supposing base was renamed to newbase in this case). Instead of Haskell code, a cabal file that just says, in order to depend on this "package", you (meaning the cabal mechanism, not the users) need to depend on this set of packages instead - which is repeatedly expanded until only ghc-packages (or the equivalent for whatever compiler it is) are in the list. Isaac