Cabal 2.0 asks ghc to build modules that are #ifdefed out

[joeyh]

git-annex fails to build using Cabal 2.0 (via stack with resolver: nightly-2017-07-31). An example of the problem is its Utility.LockFile module, which contains:

#ifndef mingw32_HOST_OS
import Utility.LockFile.Posix as X
#else
import Utility.LockFile.Windows as X
#endif

Building on Linux, this fails:

/home/joey/src/git-annex/Utility/LockFile/Windows.hs:16:1: error:
    Could not find module ‘System.Win32.Types’

Previous versions of cabal did not have this problem. Looks like cabal is now running ghc with --make --no-link and a list of every module listed in the cabal file, including modules that are never used for the current OS and current set of build flags.

[ezyang]

Workaround is to use if os(Linux) etc. to conditionally include a module in other-modules or not, depending on whether or not you want it built

[joeyh]

Edward Z. Yang wrote:

Workaround is to use if os(Linux) etc. to conditionally include a module in other-modules or not, depending on whether or not you want it built

Yes, or replicate the #ifdef all around the contents of the module. However, I hope this breakage was not intentional.

…

-- ee shy jo

[hvr]

However, I hope this breakage was not intentional.

Well, the breakage of git-annex obviously wasn't intentional; it was collateral damage as a result of fixing inconsistencies in Cabal's behaviour. Just like when GHC's typechecker improves and in the process starts rejecting more programs which shouldn't have typechecked in the first place.

[joeyh]

Herbert Valerio Riedel wrote:

However, I hope this breakage was not intentional. Well, the breakage of git-annex obviously wasn't intentional; it was collateral damage as a result of fixing inconsistencies in Cabal's behaviour. Just like when GHC's typechecker improves and in the process starts rejecting more programs which shouldn't have typechecked in the first place.

Except in this case, ghc --make still builds the programs which cabal now fails to build. And I'm not aware of any bug which this new bahavior of cabal prevents either.

…

-- see shy jo

[23Skidoo]

And I'm not aware of any bug which this new bahavior of cabal prevents either.

If you don't specify other-modules/exposed-modules correctly, the tarball produced by cabal sdist will be broken. So GHC 8.2 added a warning about module names not listed on the command-line to prevent that situation. Which requires Cabal to actually pass all module names from other-modules/exposed-modules to GHC. See also #1746.

[hvr]

In addition to what @23Skidoo mentioned, cabal new-build requires accurately specified main-is/exposed-modules/other-modules for its file monitoring to work correctly; moreover in the future GHC may be able to optimise its module import logic if it's told all modules upfront rather than having to discover and locate them recursively on its own.

[ezyang]

Do we need a doc update for this ticket?

[23Skidoo]

It'd be nice, but I'm not sure in which part of the manual we should put it.

[hvr]

If there's no better idea, we could just clarify the wording in http://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-other-modules

which already specifies e.g. the invariant that

Every module in the package must be listed in one of other-modules, library:exposed-modules or executable:main-is fields.

which should be clarified that this is actually per-component, rather than per-package, as well as that all modules specified via those 3 facilities are passed to the compiler.