This was a fresh install on my home machine, in fact. I would need too many iterations on Appveyor to try it there right away.
Yes, this is why I consider the MSVC solution a temporary stop-gap until I find the time to get something better. Note that CxxWrap only interfaces with the C++ part, which should usually compile with a recent MSVC compiler. Any external C or Fortran libraries can be built using whatever compiler works. On the other hand, there may be users who want to wrap a library that is developed mainly using MSVC, so it’s impossible to predict which choice is best for potential CxxWrap users. Until the problem presents itself, I might as well go with MSVC, it seems to me. If a concrete problem crops up for a package we can deal with it then. Right now, my concrete problem is that there is no simple solution for QML.jl (32 bit especially) except for MSVC. If you want, I can put a summary of this discussion in the CxxWrap readme to warn developers.
I understand none of this is ideal, but building QML.jl in cross-compile mode is also far from ideal from my point of view: it requires maintaining a completely different build script just for the windows binaries, and this would need to be run manually for every release, and no master branch binaries would be available. The result is then even sub-optimal, with only Qt 5.5 being available, which has some gaps (I haven’t checked how important) in windows 10 support and which lacks high-dpi support on Windows. Compare this to MSYS2 or MSVC, where either the very latest Qt or at least version 5.6 (an LTS release) is available, and all it takes to build a binary is a push to GitHub (all taken care of by a fairly simple AppVeyor script).
For now, I think using MSVC for CxxWrap and its dependents should be workable, there is also Conda (as already used by PyCall.jl) that can also be used as a source of MSVC-compatible binaries for hard-to-build dependencies. If an issue comes up, I’m willing to put in more effort to solve it then, but until there is a concrete case I would much rather focus on getting the next CxxWrap+QML release out (and the embryonic Trilinos.jl, which is actually relevant for my work, go figure ;).