[wg-windows] Identifying windows ports for build systems & cross compiling distinctions

Daniel Bünzli daniel.buenzli at erratique.ch
Tue Jun 30 17:58:21 BST 2015


Hello,  

In the context of building things, one apparently needs to be able precisely identify the windows ports in order to produce build artefacts with correct extensions (see [1]). It seems that: 

1) Using the OCaml MSVC ports, windows specific extensions are used
2) Using the OCaml mingw ports, unix extensions are used
3) Using the OCaml cygwin port, unix extensions are used

The problem is that at the moment various detection bits e.g. [2] conflate 1) + 2) under a single variable, namely win32. Something is needed to distinguish them in build systems in general.

Here are a few ideas:

a) Introduce a new toolchain variable, that specifies the toolchain used, whatever that means. 
b) Distinguish an OS for the mingw ports 
c) Distinguish these 3 cases through a distribution variable [3]

I have the impression that a) is going to introduce again more noise, names and branches in the eco-system which already has plenty enough. Regarding c) I think it would be bending the semantics of the variable. Given that cygwin is already treated as an OS I would suggest that we rather use b) and introduce a "win32-mingw" or "mingw" (or whichever name windows users would find accurate) value for OS like variables. 

Besides for cross compilation of packages we need to distinguish between `build-os` and `host-os` (os on which the build products are run). It would be nice if opam could somehow provide variables for these values for build systems to use in order to configure packages properly. IIRC opam currently only has an `os` variable which has the value of `build-os` but is currently being used for `host-os` semantics. 

Note that some other variables pertaining to the capabilities of the installed OCaml compilers see [4] will also need {build,host}-os distinction (e.g. `ocaml-native` and `ocaml-native-dynlink`). In order to remain backward compatible with the current repository, I guess that the simplest is to deem all current variables as having host semantics and introduce only new variables for build semantics i.e. `build-os-ocaml-native`, `build-os-ocaml-native-dynlink`, `build-os-ocaml-version`, etc.

Best,

Daniel

P.S. To windows users. I would also be interested in knowing if there is a tool invocation that is actually able to distinguish between 1) and 2).

[1] https://github.com/dbuenzli/topkg/issues/11#issuecomment-117050094
[2] https://github.com/ocaml/opam-depext/blob/d94f9f06e1d489dc4f946fb3aa37589eb9e9a2ec/depext.ml#L62-L74
[3] https://github.com/ocaml/opam-depext/blob/d94f9f06e1d489dc4f946fb3aa37589eb9e9a2ec/depext.ml#L76-L109
[4] https://opam.ocaml.org/doc/manual/dev-manual.html#sec37




More information about the wg-windows mailing list