Always generate the manifest

[Timmmm]

This fixes an annoying issue where the sail -version output does not get correctly generated unless you manually delete manifest.ml. If you do not then Dune will see that manifest.ml already exists and assume it is up-to-date, which isn't the case if you've switch branch or commit since it was last generated.

This does mean that sail_manifest is always run, but it seems to be very fast so I don't think it's an issue.

Fixes #204

[github-actions]

Test Results

   12 files  ±0     24 suites  ±0   0s ⏱️ ±0s
  740 tests ±0    740 ✅ ±0  0 💤 ±0  0 ❌ ±0 
2 468 runs  ±0  2 467 ✅ ±0  1 💤 ±0  0 ❌ ±0 

Results for commit 47dccfa. ± Comparison against base commit c2fe0d4.

[Alasdair]

I think the issue is when you build via opam install, then opam generates that file and we don't want dune to generate it. That's why I made it a fallback rule.

[Timmmm]

I've had so much trouble with opam I always use make/make install which just runs dune directly. Do you know if Dune uses file checksums, or mtime for cache invalidation?

[Alasdair]

I think adding (deps (universe)) to the rule will fix it. If the file has not been generated by opam, then that says the dependencies are too complex to specify so dune will never cache the result.

[Alasdair]

Ah, I saw you removed (mode fallback) and went away to think about how to fix it. I just noticed you made it always build by also adding (deps (universe)). 😄

I think the trick is we can have both (mode fallback) and (deps (universe)) which is the behaviour we want in all cases.

[Alasdair]

Now I've carefully read some of the dune documentation a bit more I wonder if there is a way to use (promote) rules to cut down some of the build dependencies...

[Timmmm]

Oh I see, I misread your comment about opam.

I think I looked into (promote) a while ago when I was trying to make go-to-definition work with generated files, but IIRC there's a gotcha in that it doesn't do anything in release mode. Something like that anyway.