Variable expansion in env fields on Windows

[rjbou]

If we take the example of pkg-config, there is

setenv: PKG_CONFIG_PATH += "%{lib}%/pkgconfig"

On cmd, opam env gives

set PKG_CONFIG_PATH=C:\opamroot\switch\lib/pkgconfig

opam should handle present separators in opam files?

[MisterDA]

Duplicate of #4690?

[kit-ty-kate]

@AltGr and I discussed that at the meeting and we can’t really find a totally satisfying solution that doesn’t involve changing the opam syntax. The best we could find would be to automatically change / to \ on Windows if:

• the string is in build-env or setenv
• the string is not a triple-double-quote type string (requires a small change in the API of opam-file-format but not to the syntax)

Another solution i just thought of after the meeting, would be to use a builtin extra x-* field. For example:

setenv: PKG_CONFIG_PATH += "%{lib}%/pkgconfig"
x-allow-env-path-rewrite-on-windows: true

This way the rewriting is made explicit (x-allow-env-path-rewrite-on-windows would be false by default). What do you think @AltGr?

Overall discussion also related to #2927

[AltGr]

Hm the additional field feels slightly clunky, but has the good point of being completely explicit and allowing a reasonable workaround to unblock this.

We might consider making it true by default though ? While less satisfactory in that it allows some magic "by default", that remains limited to the Windows scope where we can assume the package wouldn't have worked anyway...

[avsm]

This seems like a good reason to bump opam-version and adopt the new semantics if the package adopts the higher version number.

[rjbou]

We should also add a lint that raise a warning if an env variable in build-env or setenv is defined with / and no x- field is defined.
This will help to set the default to false, and make package manager aware of some windows constraints.

[rjbou]

related #2927

[kit-ty-kate]

This seems like a good reason to bump opam-version and adopt the new semantics if the package adopts the higher version number.

We can’t do that because opam 2.0 and 2.1 don’t support having opam files with unsupported versions (#5631), and doing a full repository transition like it was done for the transition from opam 1.2 to opam 2.0 requires tools, resources and time we do not have.

[rjbou]

setenv is also defined for switch-config files.