[cfe-dev] Distinguishing between clang Window versions

[Alp Toker]

On 10/07/2014 01:22, Nico Weber wrote:
> On Wed, Jul 9, 2014 at 3:01 PM, Edward Diener 
> <eldlistmailingz at tropicsoft.com 
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>     On 7/9/2014 2:40 PM, Reid Kleckner wrote:
>
>         On Wed, Jul 9, 2014 at 7:09 AM, Edward Diener
>         <eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>
>         <mailto:eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>>> wrote:
>
>             I see where a build of clang on Windows using VC++
>         produces both
>             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
>         mode is
>             mingw/gcc clang emulates mingw/gcc. Even with the latter
>         on Windows
>             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
>         in Boost
>         Build?  If you're willing to do a test compile, you can look
>         for '#if
>         defined(__clang__) && defined(_MSC_VER)' or '#if
>         defined(__clang__) &&
>         defined(__GNUC__)'.
>
>
>     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:


commit 2c57a610f4b339283f5e4f171bf0d5b6b95f2b5a
Author: Alp Toker <alp at nuanti.com>
Date:   Sun Jun 22 04:31:15 2014 +0000

     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.

Alp.




>     while also taking into account the -target option on the command line.
>
>     BTW I could not find in the latest clang 3.5 documentation any
>     mention of the -target option. Likewise, and I am sure you have
>     heard it before, an alphabetical list of all clang options in the
>     documentation, with explanations for each one, would be greatly
>     appreciated.
>
>
> clang --help prints a list of all driver options, with at least some 
> help text.
>
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
http://www.nuanti.com
the browser experts