[cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.

[Chaoren Lin]

Makes sense. Thank you.

On Thu, Aug 4, 2016 at 6:53 AM, Brad King <brad.king at kitware.com> wrote:

> On 08/03/2016 03:22 PM, Chaoren Lin wrote:
> >> It will take some investigation to decide how/whether to set SIMULATE_ID
> >> to GNU.
> >
> > This seems like the right thing to do, and is more future proof than the
> alternative.
>
> This patch may do it.
>
> ```patch
> diff --git a/Modules/Compiler/Clang-DetermineCompilerInternal.cmake
> b/Modules/Compiler/Clang-DetermineCompilerInternal.cmake
> index 08c1230..a8ef61b 100644
> --- a/Modules/Compiler/Clang-DetermineCompilerInternal.cmake
> +++ b/Modules/Compiler/Clang-DetermineCompilerInternal.cmake
> @@ -12,4 +12,6 @@ set(_compiler_id_version_compute "
>  set(_compiler_id_simulate "
>  # if defined(_MSC_VER)
>  #  define @PREFIX at SIMULATE_ID \"MSVC\"
> +# elif defined(__GNUC__)
> +#  define @PREFIX at SIMULATE_ID \"GNU\"
>  # endif")
> ```
>
> However, I remember now why we didn't do this before.  For MSVC, Clang
> actually tries to look a lot like `cl`.  It defines _MSC_VER to a
> version matching the compiler's standard library.  OTOH for GNU, Clang
> is not trying to look like a specific version.  It always defines
> __GNUC__ to 4 and __GNUC_MINOR__ to 2, regardless of what standard
> library is used.  Essentially Clang is acting as a standalone compiler
> that happens to use a GNU standard library as an implementation detail.
>
> Therefore I've decided to go with the direct approach.  Please
> try out this change:
>
>  Ninja: Fix response file format for GNU-like Clang on Windows
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e555480c
>
> Thanks,
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160804/2d38164b/attachment.html>