Regarding the “Make your executable available under cram tests” section, there’s a fourth way that I really like. Namely, using (env ...) with (binaries ...): env - Dune documentation.
The benefit is that you can make certain executables available in tests, as if they’re public/installed, without actually making them public/installing them. All while avoiding a bunch of relative path business.
This is good for having some cram test utility executables (e.g. for stripping some custom output to make it deterministic). You wouldn’t want to make them public/install them, but referring to them by a long relative path through some cram test folder hierarchy is also annoying. This solves both problems.