I would solve this with the help of flags
cppstuf.cabal
-file
name: cppstuf
version: 0.1.0.0
...
cabal-version: >=1.10
flag StableRelease {
Description: Stable release settings like port ...
Default: False
}
executable cppstuf
main-is: Main.hs
build-depends: base >=4.9 && <5.00
default-language: Haskell2010
extensions: CPP
if flag(StableRelease) {
GHC-Options: -DSTABLE
}
Main.hs
module Main where
main :: IO ()
main =
#if STABLE
putStrLn "Hello, Haskell!"
#else
putStrLn "Hello, Haskell?"
#endif
and compiling it
stack build
or
stack build --flag cppstuf:stablerelease
Personal Note aside from the answer
I would not use CPP to manage configuration options - either providing command-line options I like optparse-applicative but there is also cmdargs,and or a configuration file I have used configurator for that, but there are several options out there on hackage. One being configurator-ng as @Shersh said - the other one is not being developed anymore.
CPP
on the other hand I tend to use for making libraries work across multiple GHC/library versions.
Update - w\ regards to the comment.
- If I deliver a program, the operations team should be able to change ports, hostname or handle file location of input files etc. without knowing haskell let alone recompiling a project.
- It makes error chasing a lot easier if your production source code does not differ from your development sources, say you would have a postgres db in dev mode, but an oracle in production - you'll never find the oracle specific bug.
- For things like optimization levels - I don't mind too much.
- But make sure you test multi-threaded stuff properly, I once ran out of file handles because I was opening a lot but not closing fast enough - If your dev-setting is single threaded you'll deliver a bug.