Coexistence of BinaryBuilder and MSVC

[Petr-Hlavenka]

I've used CxxWrap to interface our internal library that is a pure Win64 MSVC styled code - no chance to get in compiled under mingw. On the other hand, libcxxwrap-julia let itself compile with MSVC 2019 and it works quite well.
So, the question is, how to mix in one julia process a package that uses BB-libcxxwrap-julia and an other package that relies on MSVC. For now, I've forked both libraries, changed their names to contain *_MSVC and everything works well. But, it would be great if somehow the packages could specify which build of binaries should CxxWrap use to do the '@wrapmodule' magic.
Do you have any idea how to solve it in a more clean way?

I'd like to emphasize how much I do thank you @barche for the incredible work you do.

[barche]

That is indeed an issue. My proposed solution for that would be to build binaries on AppVeyor using MSVC. This is already done for libcxxwrap, but when combining several CxxWrap-based packages they all need to be built using the same compiler.

The "quick fix" for this would be to define an environment variable and agree on a standard naming for binaries that will make libcxxwrap and its users choose the correct version of binaries in the build script. This relies on authors supporting the MSVC builds manually however.

A much better long-term solution would be to add support for MSVC as an extra Windows platform in the BinaryBuilder ecosystem. CC @staticfloat

[staticfloat]

Hmmm.... I'm not sure we're ever going to be compiling with MSVC, since BB is all built on top of Linux, and MSVC doesn't work there. ;)

On the other hand, there are (limited) cases where we can. This comment gives a nice list of things that can go wrong when mixing MINGW and MSVC binaries within the same process; for our purposes we mostly care about the last bullet point. It seems to be that it's not impossible, but things can rapidly get complicated once you step outside of the "simple" test cases. C should generally work, but C++ will quickly get into an issue because there are differing internal representations for things like std::strings or class memory layouts, etc...

I'm not sure what the right API here is, because I believe what you're attempting to do is to load semi-compatible libraries on a system where you want that decision to influence the choice of other, unrelated packages. (e.g. "if I have the MSVC version of LibFoo, then grab the MSVC version of CxxWrap. Is that about right?

[barche]

Yes, basically it would be nice for users to have an option to say "I want MSVC for binaries" (on a specific environment), and then it would load the MSVC versions of binaries, or fail otherwise. That way, the only potential compatibility issue is with libjulia itself, but this has been proven to work, at least for CxxWrap and QML. I fully expect this would be a less supported platform, but technically it seems feasible to use AppVeyor to generate the actual binaries? Maybe a separate package to do the actual building, but using the same infrastructure for distribution?

[Petr-Hlavenka]

Thank you @staticfloat for thinking about it. I've skimmed through the comment link and I think only the 4th point actually matters. the good think is that Julia ABI is C-only and therefore it shouldn't be such a mess that C++ incompatibiliy makes as long as CxxWrap's DLL (C++ code) build-tools matches the MyWrappedDLL.
During the MyWrapped package initialization, I'd like to ask CxxWrap to load with certain CxxWrapDLL-MSVC artefact that MyWrappedDLL was build against. And if another package also needs CxxWrap but uses standard cross-compile build, than it can independently load the CxxWrapDLL-mingw as default.

One thing that is not clear to me is, what is the Julia ABI compatibility strategy - BB is building against 1.0.x? And we keep the headers and libs untouched during the whole 1.x lifetime?

[SylvainCorlay]

In a way, this also raises the question of why Julia is built with mingw on Windows instead of the main platform compiler.

It makes Julia windows builds hardly reproducible, since the entire stack (including LLVM) must be built with mingw... For distributions such as conda-forge, this would require having mingw variants of the entire llvm stack... The only viable way to use Julia on Windows is to use an official build from https://julialang.org/downloads/ - which is not great for an open-source project.

[traversaro]

In a way, this also raises the question of why Julia is built with mingw on Windows instead of the main platform compiler.

I think you can find some background info in the issue JuliaLang/julia#12056 . I guess the main limitation has always been the availability of a fortran compiler that produce code that links the MSVC's CRT, see microsoft/vcpkg#485 for a related issue.