I see where a build of clang on Windows using VC++
clang.exe and clang-cl.exe and that they are both the same
executables. Nonetheless depending on the -target ( or default
-target ) passed to the clang driver we have different build
expectations in Boost Build. In Windows When the target
mode is VC++
clang emulates VC++ in various ways and when the target
mingw/gcc clang emulates mingw/gcc. Even with the latter
there are a few subtle differences from clang on Linux.
That is why
Boost Build needs to treat them differently from within
its .jam files.
What kinds of properties of a compiler do you normally check
Build? If you're willing to do a test compile, you can look
defined(__clang__) && defined(_MSC_VER)' or '#if
That is another possibility which I will bring up in Boost Build.
Essentially we need to find out as easily as possible whether a
clang executable on Windows targets vc++ or gcc/mingw,
I think going forward, the idea is that "clang" will try to be gcc-compatible (i.e. target minw), while "clang-cl" will try to be cl-compatible and targes vc++.
That's not quite right. The only difference between 'clang' and 'clang-cl' is in the way they parse the command-line and how they invoke tools, but either should be able to target any supported triple, cross-compile to Linux etc.
'clang-cl' currently falls short of that and is hard-coded to target VC++ but 'clang' is already more or less able to do everything 'clang-cl' does.
Then there's the question of the *default* target triple. We know for sure what it has to be for the cl driver mode -- no problem there, but there's still uncertainty around what the default triple should be for the standard clang.exe driver mode..
Basically we need to pick a sane default target triple for 'clang.exe' on Windows and make sure all native Windows builds of clang default to that triple (regardless of whether they were produced by MSVC, MinGW or whatever). The fact we have binaries that differ only in default target triple is a leftover from when MSVC and MinGW produced functionally different clang binaries, which I fixed a couple of weeks ago in r211461:
Author: Alp Toker <firstname.lastname@example.org>
Enable WindowsToolChain on all native Windows builds
Make binaries built by MSVC, mingw and clang functionally equivalent. The
checks are trivially performed at runtime to eliminate functional differences
between supported configurations that used to be hard-coded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211461 91177308-0d34-0410-b5e6-96231b3b80d8
So yes, we should avoid this awkward situation where we're ending up with 'clang.exe' binaries in the wild that differ *only* by their default target triple. Which default we choose doesn't matter much as long as there's consistency between all native Windows builds of clang.