If we `make clean` outside of the nix shell,
we can't necessarily get back in.
Certainly, `make shell` doesn't work.
But, building `default.nix` might not work if `hpack` doesn't exist.
We want to start parameterizing jobs on the version of GHC.
This is the first step.
Should also make things quicker as there's no interleaving of jobs.
With nix, we get more reproducable builds.
Everything that goes into making the build can be specified.
The dependencies we need for development/CI can be made the same.
And, we ought to be able to parameterize the build better.
When we want to check if things compile on 8.4.x,
we can change the compiler to that version in one place.
Assuming this works out, it should make for a lower amount of overall work.
We want a check that the build succeeded on GitHub.
Unfortunately, circleci doesn't give us a final result from a workflow.
We hack around it by making one job that does nothing really.
Hopefully they can provide a better interface for this in the future.
It looks like,
when we switch jobs in CI the new checkout has newer timestamps
than what's in the make cache.
Rather than dealing with that anymore, we alter the targets.
We can change `test` to ensure builds are up to date.
Then we can leave the individual test targets to run whatever is there.
In CI this means we can set the workflow to run the tests separately.
If we don't do this, the test job will try to rebuild everything.
That defeats the purpose.
Probably, we've got our Make dependencies/targets setup improprerly.
I had an older version of `cabal`.
It didn't check that the `description` was longer than the `synopsis`.
The `cabal` on CI is newer.
It would be nice if everything used the same programs.
Might look into using a specific `docker` image or `nix` for this.
Since we use `stack` to run `hpack` to generate the cabal file,
we need `stack` to have its cache all setup properly.
We could eschew `hpack` to relax this requirement...
