Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,831
    • Issues 4,831
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 447
    • Merge requests 447
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #3457

Closed
Open
Created Aug 23, 2009 by duncan@trac-duncan

Impossible to specify pragmas compatible with multiple ghc versions

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 (closed) and #2464 (closed)). 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.

Trac metadata
Trac field Value
Version 6.10.4
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Driver
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking