(Imported from Trac #890, reported by @batterseapower on 2011-09-28)
If you turn on detailed build reports with --build-log=foo.log then cabal-install uses the external setup method for a package rather than the internal setup method.
If you try to use the external setup method with the "base" package then compiling the setup executable like this fails:
/usr/bin/ghc -v --make ./dist/setup/setup.hs -o ./dist/setup/setup -odir ./dist/setup -hidir ./dist/setup -i -i. -package-conf /Users/mbolingbroke/Programming/Checkouts/hackage-server/hackage-build/build-cache/local.conf.d -package Cabal-126.96.36.199
*** Chasing dependencies:
Chasing modules from: *dist/setup/setup.hs
Prelude.hs:38:2: lexical error at character 'i'
(Imported comment by @batterseapower on 2011-09-28)
If you were to instead build the setup executable as follows it would work flawlessly:
cd dist/setup && /usr/bin/ghc -v --make setup.hs -o setup -package-conf /Users/mbolingbroke/Programming/Checkouts/hackage-server/hackage-build/build-cache/local.conf.d -package Cabal-188.8.131.52
Or even more mininally, just remove the -i.:i.e. remove "-i" ++ workingDirfrom SetupWrapper?.hs:295. Is there a good reason for this to be here? You probably only want it when you are compiling the Cabal package itself.
Never mind, we can't remove -i. without breaking packages that import other modules from their Setup.hs. And anyway compiling "base" with Cabal fails even if you fix this particular bug.
(Imported comment by @dcoutts on 2011-09-30)
It would be nice however to be able to specify external packages that custom Setup.hs depends on, and when adding that feature we could also add a way to stick setup src files in a subdir. That ought to fix the immediate problem. As you say, there's bigger issues for compiling base separately from the ghc build process. It would be nice though, e.g. for creating new sets of libs for cross-compilation.