graphql-engine/cabal.project.dev-sh.local
Robert b73ce89205 server: remove cabal flag "developer"
The only purpose was enabling the developer API by default. I don't
think that justifies a flag and CPP usage.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3820
GitOrigin-RevId: 058c9a7b03e5e164ef88e35c42f50bae3c42b5b6
2022-03-01 11:41:45 +00:00

53 lines
2.3 KiB
Plaintext

-- This is the local cabal configuration file used by the 'scripts/dev.sh'
-- development script, which uses `... --project-file=cabal.project.dev-sh`
-- which in turn consults this file.
--
-- You can temporarily override values here rather than modifying 'dev.sh'
-- during development (although that might break certain things).
with-compiler: ghc-8.10.7
package *
documentation: true
-- build with DWARF support. This may not be very useful yet, but we want
-- to be able to experiment with it, and turning it from off to on requires
-- a massive rebuild. To start, see:
-- https://www.haskell.org/ghc/blog/20200403-dwarf-1.html
debug-info: 2
-- For compile-time performance (see cabal.project.ci.local):
ghc-options:
-- We compile with package-level parallelism, so just use a small amount
-- of module-level parallelism for dependencies:
-j2
+RTS -A64m -n2m -RTS
-- Modify this to '+optimize-hasura' to enable optimizations. Be sure also to comment
-- 'coverage: true' below for full prod performance.
--
-- NOTE: new-build may report a misleading 'Build profile: -O1'
-- See:https://github.com/haskell/cabal/issues/6221
flags: -optimize-hasura
package graphql-engine
documentation: false
-- NOTE: 'cabal new-build --enable-coverage' seems to rebuild all deps with coverage
-- which is not what we originally wanted. But building the test modules
-- themselves with coverage is actually nice for validation.
coverage: true
-- to match CI:
ghc-options: -Werror
-- For compile-time performance (see cabal.project.ci.local):
ghc-options: -j
-- By default GHC is dynamically linked, so to run TemplateHaskell you need dynamic versions of
-- libraries. But, also by default, cabal links executables statically, which requires static
-- versions of the libraries. Therefore, by default, cabal builds with -dynamic-too to generate
-- static and dynamic versions of all object files.
-- Setting executable-dynamic: True forces cabal to build a dynamic executable; but it's not
-- enough on its own: since library-vanilla defaults to True, cabal would still build a static
-- library. With those two flags together, we can finally only build one version of the library,
-- which substentially improves compilation time.
executable-dynamic: True
library-vanilla: False