diff options
author | Ben Sima <ben@bsima.me> | 2020-04-03 13:20:29 -0700 |
---|---|---|
committer | Ben Sima <ben@bsima.me> | 2020-04-03 15:13:56 -0700 |
commit | 87b48d473bdb41670c9f3b26a628f34c3c5c9481 (patch) | |
tree | 9d515f4e5c49336e4db21b1892b8a0022e74682d /Run/Que | |
parent | 65c2b30a288385cf3df4027d50080ac595bbcf83 (diff) |
Rewrite buildGhc and buildGhcjs
I wanted to even further simplify the build tooling overhead. My general
goal is to not have to think about declaring packages, or dependencies,
or really anything that you might find in a cabal file. Not all of these
goals are possible, but we can get pretty close. With this commit all I
need for the 'buildGhc/buildGhcjs' functions is the path to the
entrypoint file; everything else is either inferred by the Nix code or
declared in the Haskell code comments.
The strategy is to map a Haskell module to an executable artifact, and
pass just that module to 'ghc --make'. Then we can rely on ghc to handle
walking the local filesystem for imports. The only thing ghc really
needs to know is a name for the output executable; it is hard to
automatically infer this, so we have a simple comment syntax to declare
this in the file. The comment syntax is inspired by existing Haskell
'LANGUAGE' pragmas; having this in the same file keeps the configuration
as close to the real code as possible. The Nix code then extracts this
info from the code comments, and sets the required ghc flags.
Second, we need to declare the set of 3rd-party packages that our
program relies on. For this we can re-use the same comment syntax and
just list the dependencies, then extract them in Nix and construct a
package set as we were before.
This reduces the amount of "package declaration" code we have to write
in default.nix, and reduces the amount of time we have to spend
switching between the Haskell code and the Nix code (I find such context
switching super annoying). I also think having the configuration in with
the Haskell code encourages us to write smaller, simpler modules and
only write code that we need.
Additionally, I refactored the bild and ghci (now called 'repl') scripts
to work in any directory. The .envrc uses direnv to set the path so that
you can run these scripts anywhere. That means the following works:
$ cd Run/Que
$ bild Website
$ repl Server
λ> :l Run.Que.Server
I find this to be a rather nice workflow.
Diffstat (limited to 'Run/Que')
-rw-r--r-- | Run/Que/Server.hs | 11 | ||||
-rw-r--r-- | Run/Que/Website.hs | 6 |
2 files changed, 15 insertions, 2 deletions
diff --git a/Run/Que/Server.hs b/Run/Que/Server.hs index e5094cd..4974498 100644 --- a/Run/Que/Server.hs +++ b/Run/Que/Server.hs @@ -3,8 +3,15 @@ {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE LambdaCase #-} -{- | Interprocess communication --} +-- | Interprocess communication +-- +-- : exe que-server +-- : dep async +-- : dep protolude +-- : dep scotty +-- : dep stm +-- : dep unagi-chan +-- : dep unordered-containers module Run.Que.Server ( main ) diff --git a/Run/Que/Website.hs b/Run/Que/Website.hs index 910d97b..757f5e6 100644 --- a/Run/Que/Website.hs +++ b/Run/Que/Website.hs @@ -4,6 +4,12 @@ {-# LANGUAGE LambdaCase #-} -- | spawns a few processes that serve the que.run website +-- +-- : exe que-website +-- : dep async +-- : dep process +-- : dep protolude +-- : dep req module Run.Que.Website where import qualified Control.Concurrent.Async as Async |