You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a deliberate decision that packages cannot depend on package + flag combinations, only on packages. The point is that flags are not supposed to change the API of a package.
if flag(gtk)
build-depends: gtk >= 0.9.11
exposed-modules: Graphics.Rendering.Chart.Gtk
The criterion package depends on Chart and imports Graphics.Rendering.Chart.Gtk meaning that it breaks if you build Chart with the gtk flag turned off.
The solution is that Chart should be prevented from conditionally exposing modules. We should add a QA check that looks for exposed modules that are conditional on a flag. It is annoying but somewhat less bad for modules to change between platforms.
Should it be a hard failure or just a warning?
The text was updated successfully, but these errors were encountered:
(Imported from Trac #788, reported by @dcoutts on 2011-01-11)
It is a deliberate decision that packages cannot depend on package + flag combinations, only on packages. The point is that flags are not supposed to change the API of a package.
This needs to be enforced.
Consider a real example (from Chart package: http://hackage.haskell.org/packages/archive/Chart/0.14/Chart.cabal)
The criterion package depends on Chart and imports Graphics.Rendering.Chart.Gtk meaning that it breaks if you build Chart with the gtk flag turned off.The solution is that Chart should be prevented from conditionally exposing modules. We should add a QA check that looks for exposed modules that are conditional on a flag. It is annoying but somewhat less bad for modules to change between platforms.
Should it be a hard failure or just a warning?
The text was updated successfully, but these errors were encountered: