GHC's CPP and Cabal's unlit
I'm doing some testing with GHC 6.6.1 and Cabal 1.3, and I'm trying to figure out what happens with CPP and Cabal's unlit. I start with file Test.lhs:
{-# OPTIONS -fglasgow-exts #-} module Test where main = putStrLn "hello CPP"
and run command: ghc -E -x hs -cpp Test.lhs -o Test2.lhs which gives me Test2.lhs: {-# LINE 1 "Test.lhs" #-} # 1 "Test.lhs" # 1 "<built-in>" # 1 "<command line>" # 1 "Test.lhs"
{-# OPTIONS -fglasgow-exts #-} module Test where main = putStrLn "hello CPP"
So I'm wondering: where does the {-# LINE #-} comment come from, and also the # 1 lines? AFAICT the # 1 lines are ignored by GHC; I can compile Test2.lhs without errors. Is there anything in GHC's docs about this? More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this: {-# LINE 1 "Test.lhs" #-}
{-# OPTIONS -fglasgow-exts #-} module Test where main = putStrLn "hello CPP"
which is not a valid .lhs file, because we have a code line next to a comment. I also note in Cabal the haddock command runs CPP before unlit. GHC does it the other way around i.e. run unlit first then CPP, and I'm wondering if Cabal shouldn't do the same thing? Thanks, Alistair
More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this:
(Answering my own message) Having done some more testing with ghc-6.8.1 and ghc-6.6.1 and cabal's 1.1.6.2 and 1.3, I've realised that the cpp optP-P option in Cabal-1.3 is suppressing the # n lines, so that means the {-# LINE 1 "Test.lhs" #-} comment does indeed end up immediately preceding the first real line of the program (thus causing unlit to spit the dummy). I've also noticed that the options passed from cabal-1.1.6.2 to the ghc cpp phase do NOT include -x hs, so ghc unlits the file before cabal then tries to unlit it. Surely this cannot work, and indeed it does not, because the resulting .hs file contains no code. I'm of a mind to fix two things in cabal: - the haddock command runs unlit first, THEN cpp - the unlit module preserves comments, for the benefit of haddock I already have these done in my local Cabal-1.3, so creating patches ought to be straightforward. I've only tested with ghc on Windows though. Comments? Thanks, Alistair
On Wed, 2007-11-28 at 22:37 +0000, Alistair Bayley wrote:
More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this:
(Answering my own message)
Having done some more testing with ghc-6.8.1 and ghc-6.6.1 and cabal's 1.1.6.2 and 1.3, I've realised that the cpp optP-P option in Cabal-1.3 is suppressing the # n lines, so that means the {-# LINE 1 "Test.lhs" #-} comment does indeed end up immediately preceding the first real line of the program (thus causing unlit to spit the dummy).
I've also noticed that the options passed from cabal-1.1.6.2 to the ghc cpp phase do NOT include -x hs, so ghc unlits the file before cabal then tries to unlit it. Surely this cannot work, and indeed it does not, because the resulting .hs file contains no code.
I'm of a mind to fix two things in cabal: - the haddock command runs unlit first, THEN cpp - the unlit module preserves comments, for the benefit of haddock
I already have these done in my local Cabal-1.3, so creating patches ought to be straightforward. I've only tested with ghc on Windows though.
Comments?
Sounds great. Send your patches to cabal-devel@haskell.org. You may also like to subscribe to that mailing list. Duncan
participants (2)
-
Alistair Bayley -
Duncan Coutts