Robert Dockins <robdockins at fastmail.fm> writes:
> [snip]
>>> So you are listing extensions in the source files rather than the
>> .cabal file, which should be OK (except that it's non-portable, of
>> course). So cabal really shouldn't have anything to do with it. So
>> it _should_ be all about how cabal is calling GHC... The question is,
>> if the cpp flag is getting to ghc, why isn't ghc itself looking for
>> the ghcconfig.h file? Looks like the difference is here:
>>>> WORKING VERSION:
>> > /opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir
>> >dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes
>>>> (...)
>>>> BROKEN VERSION:
>> > /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build
>> >-hide-all-packages --make -i -isrc Language.Cmm.Frontend
>>>> (...)
>> Removing the -hide-all-packages flag from the command line causes the package
> to compile. Apparently if package "base" is not in scope, then GHC won't
> find ghcconfig.h in the preprocess phase.
Ahh, I did not know that.
> Is there ever a reason for the base package not to be in scope? If
> cabal is going to add the -hide-all-packages flag, then perhaps it
> should also add -package base?
Build dependencies have to be exact starting with GHC 6.4.1. We added
the hide-all-package flag so that users will get exact build
dependencies in their .cabal files instead of just relying on the
packages they have on their systems. People may not want to depend on
base, for instance if they just want to be haskell98, so that's why
cabal doesn't automatically make a build dependency on base. Sorry
that this was tricky to debug.
> Adding a Build-Depends clause to my cabal file with all my dependencies fixes
> the problem.
Excellent!
peace,
isaac