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

[David Allsopp]

Daniel Bünzli wrote:
> Le jeudi, 23 juillet 2015 à 19:55, David Allsopp a écrit :
> > utils/config.mlp shows that the output will be the CCOMPTYPE variable
> OCaml was configured with; config/Makefile.{msvc,msvc64,mingw,mingw64}
> show that is "msvc" for the first two and "cc" for the second two.
> 
> Thanks very much, that's useful information on where to look at things.
> 
> > Additionally, while new code out there may be taking advantage of
> > Sys.win32, I expect there's a lot of code still reasonably expecting that
> > Sys.os_type = "Win32" will work forever.
> I'm not suggesting to change that in OCaml I'm suggesting that for the
> *opam* os variable so that build systems can condition on it an behave
> accordingly. The opam os variable is already quite different from
> Sys.os_type which is not precise enough, see [1].

Sorry - poor context-switching on my part! However, my comment still stands - mingw and msvc are not operating (sub-)systems – even the sub-splitting in that function still gives you operating systems. Having something akin to the comp_type seems better to me than (ab)using the notion of os.

This may play differently in an OPAM which fully supports cross-compilation, but would you expect that os variable to be the same across all switches? One thing that is certainly interesting (and which I'm doing in my Windows port of OPAM[*]) is being able to use all four native Windows ports in the same OPAM installation.

<snip>

> > I'm not sure what you're getting at here - what build system differences
> are you referring to?
> 
> Well the build system needs to adapt file extensions for one thing (which
> is quite annoying). Hence my question is it *only this* that differs in
> the mingw and msvc ports or are there also other differences at the build
> level (e.g. build rules) as if this is the case it would make sense to
> distinguish the ports using the os variable in order to have a good bulk
> variable to condition on, otherwise, if it's only the file extensions I
> don't think it's worth it.

Oh, I see - yes, the way the compilers and linkers are invoked is totally different (I for some reason thought you were meaning were different build systems themselves required). In GNU make, I use a function and $(call ...) to differentiate them - see, for example, https://github.com/dra27/opam/blob/0130db82f6bc49245b164d3136308531d96c786c/configure.ac#L85-L100 and https://github.com/dra27/opam/blob/0130db82f6bc49245b164d3136308531d96c786c/src/Makefile#L276.

If you have comparch = cc on virtually everything (Cygwin, Mingw, most/all Unices) and comparch = msvc for the Microsoft compilers and also os being Win32, Cygwin or a variety of Unices then you have:

comparch = msvc -> immediately .obj, .lib, .dll, .exe (and Microsoft invocation rules)
comparch = cc -> immediately gives you .o and .a and then os <> Win32 gives you .so or .dll+.exe (and CC/GCC invocation rules)

Best,


D


[*] which is, of course, a) not finished and b) not necessarily going to be merged!