Visual Studio 2010(+ all udpates)
clang: Windows snapshot builds from http://llvm.org/builds/, Windows installer, based on SVN r260114 (9 February 2016).
how to reproduce:
1. download Boost 1.60 from (boost.org, https://sourceforge.net/projects/boost/files/boost/1.60.0/)
2. open Microsoft Visual Studio Console (for building on command line)
3. build boost with VS 2010 using this command in the boost_1_60_0 directory
b2 --toolset=msvc-10.0 --libdir=lib32-msvc-10.0 --build-dir=build_dir --with-thread link=static variant=release,debug threading=multi runtime-link=static install
4. add boost_1_60_0 directory to include path, boost_1_60_0\lib32-msvc-10.0 to lib path
5. try to compile with clang-cl in VS 2010
-DBOOST_SP_USE_STD_ATOMIC may also be needed.
let me compile the cpp
is clang-cl not "compatible" enough so boost is not detecting MSVC correct or why doesn't cl need this?
another test does not compile
typedef boost::signals2::signal<void (int test)> my_signal;
BOOST + clang-cl is an mostly an untested combination. Some part of BOOST identify clang as MSVC and provide workaround MSVC or features which are not required or not compatible with clang. I reported some issues to BOOST and clang which got fixed about two months ago but there were more unresolved issues I didn’t have the time to look into.
is there a offical list of programs/libs that gets tested on daily/weekly/whatever basis?
The LLVM test-suite runs nightly.
are there msvc/clang-cl tests included for example compiling boost, qt and other big problematic projects with clang-cl?
We regularly build Chromium with clang-cl. I believe Mozilla regularly builds Firefox, and from patches going through this list it looks like the Qt folks are working on getting Qt to build with clang-cl. clang-cl tries to be very compatible with cl.exe, but for larger projects some tweaks in the project itself is usually needed. If nobody at boost is looking at this, chances are it won’t work. (See e.g. slide 88 of https://docs.google.com/presentation/d/1oxNHaVjA9Gn_rTzX6HIpJHP7nXRua_0URXxxJ3oYRq0/edit#slide=id.gbf386ccf4_0_150)
thanks for the docs
so its just not wanted for clang-cl to be absolute 100% compatible - because to be compatible means wrong in some ways
In this case, I'm guessing something in boost does `#if __clang__` and then
assumes "not windows" in that block. If that's indeed the cause, the fix
would be to not define __clang__, which isn't an option. So yes, 100%
compatibility in the sense that clang-cl defines only the built-in macros
that cl.exe defines isn't a goal.
but it would help porting if the definition of __clang__ could be temporary
disabled or a warning if its used in context of clang-cl - maybe