Introduces a subdirectory for tracking CI-specific project and freeze files
These files are named according to the version of GHC that we want to test against
By having a small amount of duplication (i.e. 1 project file per supported compiler version) we can deterministically test kriti-lang against a variety of package sets
Refactors CI to use the project files introduced in (1)
The structure introduced here also means that it should be relatively trivial for us to support additional GHC versions in the future
e.g. To support GHC 9.0.1, we would simply
Refactors the kriti-lang.cabal file to reduce duplication and introduce additional warnings and errors
The downside of (1) (and (2), by extension) is that we need to remember to bump the freeze files if we want to ensure that we're not testing kriti-lang against stale packages.
The alternative to this would be for us to add an index-state parameter to each of the project files under the ci subdirectory, and then call cabal freeze on each CI run.
The downside of this is that CI would become a bit less deterministic, as a tradeoff for ensuring that we're adequately testing the project against updates to the Haskell ecosystem.
This PR accomplishes several things:
kriti-lang
against a variety of package setskriti-lang.cabal
file to reduce duplication and introduce additional warnings and errorsThe downside of (1) (and (2), by extension) is that we need to remember to bump the freeze files if we want to ensure that we're not testing
kriti-lang
against stale packages.The alternative to this would be for us to add an
index-state
parameter to each of the project files under theci
subdirectory, and then callcabal freeze
on each CI run.The downside of this is that CI would become a bit less deterministic, as a tradeoff for ensuring that we're adequately testing the project against updates to the Haskell ecosystem.