id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
3457,Impossible to specify pragmas compatible with multiple ghc versions,duncan,,"Generally we wish to encourage modules to specify the language options they need directly in the module rather than putting them all in the .cabal file. For one thing it allows a simple `ghc --make` to work.

The `bytestring` package works with ghc-6.4 through to 6.11. As far as I can see, it is impossible to specify the language options in a way that allows the package to build using `ghc --make` for a recent ghc version while at the same time building ''at all'' with an older ghc version.

Consider the module `Data/ByteString.hs`. If we use:
{{{
{-# LANGUAGE CPP, MagicHash, UnboxedTuples #-}
}}}
Then it works with `ghc-6.8 --make` and `ghc-6.10 --make` however now it cannot compile with `ghc-6.6` because that version does not grok the `MagicHash` and `UnboxedTuples` language options.

We might think we could do:
{{{
{-# LANGUAGE CPP #-}
#if __GLASGOW_HASKELL__ >= 608
{-# LANGUAGE MagicHash, UnboxedTuples #-}
#endif
}}}
Of course we will not expect this to work with `ghc-6.6 --make` but it will at least work with Cabal, because we can set things up so that Cabal passes `-fglasgow-exts`.

However the above still will not work with `ghc --make` or even `ghc -cpp --make` because of the problem that ghc handles pragmas and CPP incorrectly (see #2800 and #2464). It holds onto the pragmas gathered before running cpp and assumes they will still be valid after the run of cpp, which of course is not true.

The solution would be that after ghc runs cpp, it looks to see what the pragmas are, just as if it were starting from a fresh .hs file.

In the mean time we cannot specify the language extensions in the `.hs` files and have it work. For `bytestring` we will just list the language extensions that we would specify if we could specify them.
{{{
{-# LANGUAGE CPP #-}
-- We cannot actually specify all the language pragmas, see ghc ticket #...
-- If we could, these are what they would be:
{- LANGUAGE MagicHash, UnboxedTuples -}
}}}
The way to test if the right ones are listed is to turn them back into pragmas and check `ghc --make`.",bug,closed,normal,7.0.1,Driver,6.10.4,fixed,,,Unknown/Multiple,Unknown/Multiple,GHC rejects valid program,Moderate (less than a day),,,,