Initial depexts for native Windows #25442
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
opam 2.2 provides integrated depext support for the Windows. This will be primarily of use for the mingw-w64 port of OCaml, rather than the MSVC port.
The main PR updating the compiler packages will demonstrate how these are integrated into the main conf- packages, but it seems worth having a separate PR where naming conventions, etc., can be discussed, and it reduces the diff of what is going to be quite a large PR...
Cygwin and MSYS2 expose the mingw-w64 compilers and libraries in a cross-compilation-like way. In Cygwin, the compilers are actually cross-compilers; in MSYS2, the packagement is cross-compiler-like, but the compilers themselves are host-native.
This creates an issue for opam-repository packaging which at present has been possible to ignore, given the general lack of first class cross-compilation support in OCaml. The fundamental issue is that the precise depext required depends on the compiler being installed in the switch. How that works will be addressed in the Windows PR, but it means that where each depext presently requires just one package, they now require additional packages for each architecture, and it is these architecture-specific packages which are in this PR.
I propose switching all of this to be done with a generator over the coming months, but I don't want to hold things up further while that's being developed/agreed/sorted, and having a PR which shows how depexts are generally handled will hopefully mean that others can be contributed manually in the meantime.
For naming convention, I've gone for
conf-mingw-w64-
(which should only be used for these packages) followed by the name of the "master" conf package (e.g.gcc
,g++
orzstd
here - soconf-gcc
,conf-g++
andconf-zstd
all should exist), followed by the name of the architecture as used by GCC (i.e. i686 / x86_64, not x86_32 / amd64, etc.).It would be possible simply to install all of these architectures in the conf- package. I have two issues with that:
I care quite a bit about the moral argument (if we're using an x86_64 compiler, why should opam start installing i686 dependencies?), but I think the space argument (especially for caching - e.g. in GitHub Actions runners, etc.) is significant.