CODEWITHSUNDEEP
haskellghccabal
chwarr
chwarr

Reputation: 7202

How do I mark my package as depending on ghc specifically?

My package depends on some implementation details in GHC (more than just language extensions). How should I express this dependency in my .cabal file? Should I? Am I just being paranoid?

build-depends

I thought that maybe I should just add ghc to the build-depends list, but there's no ghc package.

Inspired by ghc-mod's dependency list, I tried it anyway. I added build-depends: ghc >= 7.20, and this produced the expected failure when I only had 7.10.3 installed. (7.20 doesn't even exist as of this writing.)

cabal.exe: At least the following dependencies are missing:
ghc >=7.20

Is ghc some sort of magic package? What are the other magic packages?

tested-with

There's the tested-with package property. That doesn't seem affect the build, however. I added tested-with: GHC==7.20 (a version of GHC that doesn't exist but newer than the 7.10.3 I have), but cabal build still built my package and didn't even issue a warning or anything.

Upvotes: 0

Views: 44

Answers (1)

sclv
sclv

Reputation: 38891

ghc is a package, and not a magic one. It is just not a package on Hackage. Rather it is installed with your ghc install, and hidden by default. You can see it listed in the output of ghc-pkg list. It exposes an API for the compiler. If you don't actually use it, you shouldn't depend on it. In general, most people don't pin themselves to GHC unless they actually need to. For example, are you sure your package won't compile with GHCjs or with Haste? So, why limit yourself ahead of time...

If you can use your package without the implementation details in ghc, but can also do things in a "longhand" way that is more expensive, you can use the macros provided by cabal to have CPP conditionals in your code that give different results based on the test for GHC.

tested-with is indeed a purely informational field used by convention.

Upvotes: 1

Related Questions