Hi all, I've implemented this: https://phabricator.haskell.org/D1349
Cheers, Edward Excerpts from Reid Barton's message of 2015-09-25 15:15:09 -0700: > On Fri, Sep 25, 2015 at 4:09 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > > > Excerpts from Reid Barton's message of 2015-09-25 12:36:48 -0700: > > > GHC could provide MIN_VERSION_* macros for packages that have had their > > > versions specified with -package or similar flags (which is how Cabal > > > invokes GHC). That would go only a small way towards the original goals > > > though. > > > > This is exactly what the MIN_VERSION_* macros should do, and you can > > generalize it to work even without -package: you get macros for EXPOSED > > packages which are available for import. This says *nothing* about > > the transitive dependencies of the packages you're depending on, but > > it's more reasonable to have "one package, one version" invariant, > > because having multiple versions of the package exposed would cause > > a module name to be ambiguous (and unusable.) > > > Oh, I see. I had always assumed that GHC had some kind of solver to try to > pick compatible versions of packages, but having done some experiments, I > see that it always picks the newest exposed version of each direct > dependency. So we can indeed define MIN_VERSION_* macros in accordance with > the newest exposed version of each package. > > There are still some edge cases, notably: if package foo reexports the > contents of some modules from package bar, and the API of these modules > changes between two versions of package bar, then you cannot reliably use > MIN_VERSION_bar to detect these API changes in a module that imports the > reexports from package foo (since the newest installed foo might not be > built against the newest installed bar). In the more restrictive Cabal > model, you can reliably do this of course. So it could break in an existing > project. However this kind of situation (where the API of a package depends > on the version of its dependencies) should hopefully be fairly rare in > practice. > > Regards, > Reid Barton _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs