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)