Robust build infrastructure

[dhil]

This patch makes the build infrastructure for Links more robust. Previously, the build infrastructure would assume that it is running in an environment populated by OPAM. This assumption is too optimistic; for example a Docker container will give you a blank environment by default. To make it easier to install Links in such environments we now prefix dune build commands with opam exec. This command resolves the installation directory of dune and makes sure it is invoked with a suitable environment.

Furthermore, the gen_linkspath.exe install helper would only test whether Links is being built by OPAM, and if that was not the case then it would assume Links was being built from sources in a local checkout of the git repository. This assumption is a tad optimistic too. So now, if we cannot detect either an OPAM installation or the git repository, then we fall back to a best effort guess based off the current working directory.

[thwfhk]

LGTM. Tested successfully in a docker container.

[frank-emrich]

I don't quite understand the need for opam exec. To me, it seems like the only situation where dune <foo> fails but opam exec dune -- <foo> succeeds is when the user didn't run eval $(opam env). Is that correct? I'm not opposed to using opam exec, but I'd like to understand the situation better.

[dhil]

I don't quite understand the need for opam exec. To me, it seems like the only situation where dune <foo> fails but opam exec dune -- <foo> succeeds is when the user didn't run eval $(opam env). Is that correct? I'm not opposed to using opam exec, but I'd like to understand the situation better.

That's correct. It is quite annoying having to do this all the time in, say, a Docker container.

[dhil]

@thwfhk you can merge this PR when you have a minute (remember to choose the strategy "squash and merge").

[dhil]

I don't quite understand the need for opam exec. To me, it seems like the only situation where dune <foo> fails but opam exec dune -- <foo> succeeds is when the user didn't run eval $(opam env). Is that correct? I'm not opposed to using opam exec, but I'd like to understand the situation better.

That's correct. It is quite annoying having to do this all the time in, say, a Docker container.

I can expand a little upon what I said. This PR ought to remove some of the friction that you would otherwise experience when wanting to package Links as an artifact for a artifact evaluation submission. The build infrastructure is more portable as a result of this PR.

[dhil]

I think @thwfhk is correct. This PR solved the issue with Docker containers, I had simply forgotten about it!