[cfe-dev] Distinguishing between clang Window versions

[Edward Diener]

On 7/8/2014 1:29 PM, Yaron Keren wrote:
> 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.

>
> Yaron
>
>
>
> 2014-07-08 18:13 GMT+03:00 Nico Weber <thakis at chromium.org
> <mailto:thakis at chromium.org>>:
>
>     On Tue, Jul 8, 2014 at 6:54 AM, Edward Diener
>     <eldlistmailingz at tropicsoft.com
>     <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>         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)
>
>
>         Ideas ? Suggestions ?