Cross compilation: Also generate 'prefix'/'prefixexec' sections for installation

[WardBrian]

Would close #14393. Relies on ocaml/opam#6938

In summary:
Opam 2.5.1+ will ignore any target in an .install file that starts with ../, which was previously used by dune's -x to place files in the <prefix>/<target>-sysroot directory.

To allow for this use case while preserving the security benefits of disallowing parent access, opam is considering adding prefix and prefixexec to the .install file syntax, which I have implemented in ocaml/opam#6938

This PR updates dune to generate the new prefix and prefixexec sections in addition to the ../.. used before. Why both? Because of the way that opam ignores things, this means that the same generated .install files would be compatibile with any opam besides 2.5.1

opam version v / .install section >	"lib" etc with ../	"prefix"
<2.5.1	Works as intended	Ignored (opam ignores any unrecognized fields)
2.5.1	Disabled for security	Ignored (opam ignores any unrecognized fields)
2.6.0+	Disabled for security	Works as intended

[Alizter]

I'm less sure about duplicating install entries, why not move entirely to the new sections? AFAIK it will be dune install interpreting and acting upon this file anyway in the end?

[WardBrian]

AFAIK it will be dune install interpreting and acting upon this file anyway in the end?

In, e.g., opam-cross-windows, this was not true. As a work around, @kit-ty-kate recommended using dune install instead, but this required editing most of our opam files and some ugly hacks like actually deleting the generated .install file (which I don’t entirely understand, but was willing to accept as a hotfix)

It would be reasonable to remove the old generation after opam is released, but it’s also harmless to leave for compatibility IMO

[rgrinberg]

Are we OK with dropping support for older versions of opam here?

@toots can you comment on this feature?

[WardBrian]

Are we OK with dropping support for older versions of opam here?

To be clear, this PR does not currently drop support for older versions of opam; they will just ignore the added fields.
(apologies if you already knew that and your question was directed at other maintainers!)

[toots]

The approach is sound and with a wide backward compatibility. Thanks for working on this on both fronts @WardBrian

[rgrinberg]

Are we OK with dropping support for older versions of opam here?

To be clear, this PR does not currently drop support for older versions of opam; they will just ignore the added fields. (apologies if you already knew that and your question was directed at other maintainers!)

I did not know that. Thanks for letting me know.

However, I still think this change is essentially breaking? If we stop generating the .. paths, and start producing sections that only new versions of opam will understand, how are old users of opam supposed to cross compile?

[WardBrian]

@rgrinberg:

If we stop generating the .. paths

We don't stop generating them, which is the trick. opam ignores invalid fields in a .install file, but still processes all the valid ones in the same file. So, new opams consider the ../.. paths invalid, and ignore them, but will process prefix/prefixexec. Old opams consider the prefix/prefixexec sections invalid, but will still process the old ../.. paths

Assuming ocaml/opam#6938 is accepted before opam 2.6 is released, the only version of opam which won't accept anything in these files is 2.5.1, the current release

[WardBrian]

The other open question is if we'd like to support prefix/prefixexec in (install ...) stanzas. This PR does not currently, though it would be a minor extension.