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

[David Allsopp]

Daniel Bünzli wrote:
> 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

Not quite: shared libraries are .dll rather than .so

> 3) Using the OCaml cygwin port, unix extensions are used

I can't remember if Cygwin uses .so.dll or just .so, but I expect whatever it does that it fakes everything to work with just .so (just as it fakes things to work without .exe) - tricks which *do not work* when dealing with mingw-compiled programs which obviously don't have the Cygwin layer.

> 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.

$OCAMLLIB/Makefile.config defines TOOLCHAIN variable already which gives mingw or msvc. Equally, all of the required extensions can be determined by grep'ing the output of ocamlopt -config (or with more recent OCamls by using the Config module of compiler-libs.common)

> 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.

The mingw compiler already use the form w64 for the host, so that the compilers "fake" a cross-compiling triple (e.g. i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc). Perhaps that would be better?

> 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
> 
> 
> _______________________________________________
> wg-windows mailing list
> wg-windows at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-windows