[cfe-dev] Distinguishing between clang Window versions

[Nico Weber]

On Wed, Jul 9, 2014 at 6:11 PM, Alp Toker <alp at nuanti.com> wrote:

>
> 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.
>

Sure, but the defaults should be different, right?

(Once this is all figured out, there should probably be a page explaining
how to get the msvs behavior with the clang driver, and how to get the gcc
behavior with the clang-cl driver.)


>
> '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.
>

I think it makes sense that the default clang.exe triple is "gcc
compatible", and that probably means it should be some mingw triple.


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140709/080e79a9/attachment.html>