"cabal haddock" uses CPP overzealously #1808
Comments
|
Is this a regression since 1.18? I believe we never look inside the source file for extensions now so that would be a larger change. |
|
The good news is it's not a regression since 1.18. I think it might have always been an issue. I was afraid you might say it's a larger change. Oh well. |
|
I believe that |
|
I think dropping haddock 0.x is fine. |
|
Hmm. I could write cabal tests which invoke haddock. But this seems wrong from a bootstrapping PoV, because haddock I presume is built with cabal. Thoughts? |
I don't think there's a problem - it's not like you need to run the test suite to install Cabal. |
Until recently we supported ancient versions of Haddock, pre v2.0. To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output. For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.
Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.
Fixes issue haskell#1808.
Until recently we supported ancient versions of Haddock, pre v2.0. To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output. For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.
Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.
Fixes issue haskell#1808.
Until recently we supported ancient versions of Haddock, pre v2.0. To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output. For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.
Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.
Fixes issue haskell#1808.
Until recently we supported ancient versions of Haddock, pre v2.0. To
support the CPP extension with such versions, cabal had to invoke the
CPP before invoking Haddock on the output. For simplicity cabal would
invoke the CPP on all Haskell files, if any Haskell file required CPP.
However, invoking CPP on a file which does not require it can cause
build failures.
Haddock v2.0+ supports the CPP via GHC, and even automatically
preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
simply need only tell Haddock to enable the CPP when the CPP is a
package level default extension.
Fixes issue #1808.
(cherry picked from commit ba4ae3d)
The Distribution.Simple.Haddock module determines whether to run CPP before Haddock by looking at
Distribution.Package.allExtensions.Instead it should look at
usedExtensions, which isoldExtensions ++ defaultExtensions. It should also consider whether the individual source file has a{-# LANGUAGE CPP #-}pragma.Concretely, suppose I have a Foo.hs which looks like this:
And suppose I have CPP listed in Cabal's
other-extensionsbecause some other .hs file uses CPP. Then "cabal haddock" will fail:The text was updated successfully, but these errors were encountered: