Distinguishing between clang Window versions

Clang Frontend
#1

Since the two versions for clang on Windows, one using VC++ RTL and emulating VC++ to some small extent and the other using mingw rtl, are radically different, is there any easy way to distinguish between them at pre-execution time.

In Boost Build we currently have a single toolset named 'clang' for the clang compiler. On Linux it uses a clang-linux.jam file, on the Mac it uses a clang-darwin.jam file, and I am trying to establish .jam files for using clang on Windows. Essentially I can use the clang-linux.jam file with a slight modification if the clang version uses mingw, but I need to use a clang-win.jam file if the clang version uses VC++. So somewhere early in the Boost Build processing I have to determine which 'clang.exe' is being used on Windows in order to invoke the proper Boost Build jam file for it.

Ideas ? Suggestions ?

#2

E:\llvm\2013>clang --version
clang version 3.5.0 (212451)
Target: i686-pc-windows-msvc
Thread model: posix

Does the Target field should give you the information you need?

~Aaron

#3

Since the two versions for clang on Windows, one using VC++ RTL and
emulating VC++ to some small extent and the other using mingw rtl, are
radically different, is there any easy way to distinguish between them at
pre-execution time.

In Boost Build we currently have a single toolset named 'clang' for the
clang compiler. On Linux it uses a clang-linux.jam file, on the Mac it uses
a clang-darwin.jam file, and I am trying to establish .jam files for using
clang on Windows. Essentially I can use the clang-linux.jam file with a
slight modification if the clang version uses mingw, but I need to use a
clang-win.jam file if the clang version uses VC++. So somewhere early in
the Boost Build processing I have to determine which 'clang.exe' is being
used on Windows in order to invoke the proper Boost Build jam file for it.

It's not really to different clang binaries as far as I know, just the same
binary with a different default triple. So you could pass an explicit
-target parameter to force one compiler behavior over the other too.
(-target i386-pc-win32 for VC mode, -target i386-pc-mingw32 for gcc mode)

#4

You can create two Windows configurations, one for clang.exe and one for clang-cl.exe.
These are actually identical but the if I’m not mistaken the driver behaves differently based on the executable name.
So you have “clang” and “clang-cl” toolsets.

Yaron

#5

Ok, I see this. I would have to send this output to a file and then read it in and parse it, or send it through a pipe and read it back in via stdin and parse it. Thanks for the info.

#6

This is a possibility but imposes using the -target parameter on the end-user. I like to make things as end-user friendly as possible but your suggestion is a good one. Thanks !

#7

You can create two Windows configurations, one for clang.exe and one for
clang-cl.exe.
These are actually identical but the if I'm not mistaken the driver
behaves differently based on the executable name.
So you have "clang" and "clang-cl" toolsets.

That was an early thought but complicates the elegance of having a single Boost Build toolset for clang across Mac, Linux, and Windows.

#8

clang with MingW is very similar to the other platforms, while clang-cl understands a whole different set of flags, the Visual C++ ones. Thus, you can have a clang toolset for all platforms while clang-cl lives in the Visual C++ toolset.

Yaron

#9

You can create two Windows configurations, one for clang.exe and one for
clang-cl.exe.
These are actually identical but the if I'm not mistaken the driver
behaves differently based on the executable name.
So you have "clang" and "clang-cl" toolsets.

That was an early thought but complicates the elegance of having a single Boost Build toolset for clang across Mac, Linux, and Windows.

The ordinary clang driver can do everything clang-cl.exe can do. You don't need to use clang-cl.exe at all if you already have a portable clang-based build system.

If the standard clang driver is missing something to produce native binaries that's what needs to be fixed.

Alp.

#10

You can create two Windows configurations, one for clang.exe and one for
clang-cl.exe.
These are actually identical but the if I'm not mistaken the driver
behaves differently based on the executable name.
So you have "clang" and "clang-cl" toolsets.

That was an early thought but complicates the elegance of having a
single Boost Build toolset for clang across Mac, Linux, and Windows.

The ordinary clang driver can do everything clang-cl.exe can do. You
don't need to use clang-cl.exe at all if you already have a portable
clang-based build system.

If the standard clang driver is missing something to produce native
binaries that's what needs to be fixed.

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.

#11

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

There are some who believe that in the future we should stop defining these
macros for other compilers, but personally I don't see it happening.

#12

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

#13

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

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.

#14

        On Wed, Jul 9, 2014 at 7:09 AM, Edward Diener
        <eldlistmailingz@tropicsoft.__com
        <mailto:eldlistmailingz@tropicsoft.com>
        <mailto:eldlistmailingz@__tropicsoft.com
        <mailto:eldlistmailingz@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++.

However clang also creates a clang.exe driver, which is exactly the same file as clang-cl.exe, when building clang with VC++.

    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.

Yes, but the explanation is pretty terse and then the clang docs are sometimes missing any explanation for a particular option, leaving the end-user to do random guesswork or ask on the clang mailing lists.

#15

        On Wed, Jul 9, 2014 at 7:09 AM, Edward Diener
        <eldlistmailingz@tropicsoft.__com
        <mailto:eldlistmailingz@tropicsoft.com>
        <mailto:eldlistmailingz@__tropicsoft.com

        <mailto:eldlistmailingz@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++.

However clang also creates a clang.exe driver, which is exactly the same
file as clang-cl.exe, when building clang with VC++.

I think that's something we want to change. clang.exe should be the
gcc-like driver and clang-cl.exe the msvs-like driver, no matter what
compiler is used to compile clang.

#16

            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@nuanti.com>

     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.

#17

        On Wed, Jul 9, 2014 at 7:09 AM, Edward Diener
        <eldlistmailingz@tropicsoft.com
        <mailto:eldlistmailingz@tropicsoft.com>
        <mailto:eldlistmailingz@tropicsoft.com

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

#18

When using clang --help I see:

  --target=<value> Generate code for the given target

Is this the target option ( note the -- ) that can be passed to clang to change to either VC mode or gcc mode ? If so, are these two values you specify above ( "i386-pc-win32" or "i386-pc-mingw32" ) documented anywhere ? If this is not the target option you have mentioned, is that target option ( maybe with a single - ) documented anywhere ?

#19

It’s documented to some extent http://clang.llvm.org/docs/CrossCompilation.html#target-triple but we could probably do better here.

#20

It's documented to some extent
http://clang.llvm.org/docs/CrossCompilation.html#target-triple but we
could probably do better here.

The doc you cite is very different from the 'clang --help' doc:

1) In the "clang --help" it gives the target option as "--target=<value> but the doc shows the target option as "-target value". Do all options take the duplicate form, ie. "--option=value" or "-option value" ?

2) The targets given in the original answer below start with "i386" but the <arch> part of the doc specifies only "x86, arm, thumb, mips".

3) Why is the form called a "Target Triple" when it has a maximum 4 parts ?

4) All the valid possibilities for each part should be documented, with an explanation, else you are asking the end-user to play guessing games or be a mind-reader. Writing etc. does not explain anything in the doc.