bit cleaner, esp. as less hardcoding of "debug" path
instant updates all the way through to Haskell when we change Rust code
(this wasn't actually working at all before even when we did manually run the script, because TH file-dependency tracking seemed to get confused with the way that the Bash code moved a file to the header path rather than editing it)
should update to point to my comment on hs-bindgen
actually, isn't there a race condition here? the header files are generated before the new Rust code is actually compiled, and Cabal could in theory end up still linking against the old output
hardcoding "target" isn't great, though we do already do so in the Cabal file
there seems to be no env var for it though
docs suggest we're supposed to use OUT_DIR, but that has an unpredictable path... we could output the dir somewhere I suppose, and configure Cabal to use that, but that adds a fair bit of complexity
look in to https://doc.rust-lang.org/cargo/reference/build-scripts.html#change-detection?
bit blunt compared to e.g. Cabal Hooks, and anyway I think in the long run I'll be ditching `build.rs`, as discussed above
script addition is hacky, but I know no other way to get most of the build path, in arch/version-independent way
we'll use a custom setup or whatever eventually (_eventually_ hooks...) anyway
Even though `Int` and `isize` should be the same in practice, we can't cleanly convert, as the type information isn't quite there. And anyway, strictly speaking per the report, `Int` is only guaranteed to hold 30 bits.
Note that this is essentially unchanged even if we specify `usize_is_size_t = true` for `cbindgen`.
We drop the tools specifically designed for Haskell and Rust together, in favour of general tools for using each with C.
Namely, we use Mozilla's `cbindgen` for generating header files from the Rust source, and Well-Typed's new `hs-bindgen` tool for generating Haskell from those header files.
The Rust code here is essentially the result of expanding the old macro, then inlining and renaming internals.
The most important thing here is that we're now relying solely on robust well-maintained tools.
See https://sraka.xyz/posts/hs-bindgen-introduction.html.
For now, this is a shell-based workflow, rather than using Nix to build everything, i.e. `nix develop` works but `nix build` doesn't. And `cargo build` has to be called manually to create the C library, rather than `cabal` being clever enough to invoke it itself.
We ran `cargo cabal init` from the `rust` directory (`nix shell github:yvan-sraka/cargo-cabal`), which generated `hsbindgen.toml` (which we use), and `Setup.lhs` (which just added `extra-lib-dirs`, and with the wrong paths, so we dspecify those statically instead in `garnet.cabal`). We also follow its advice to use `staticlib`.
Also, after we ran the first `cargo build` (requiring a `mkdir rust/src` before it would run), we took the generated the Haskell file, and moved the main contents in to `Main.hs` manually.
