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

2016-08-04 Thread Chaoren Lin via cmake-developers 
Makes sense. Thank you.

On Thu, Aug 4, 2016 at 6:53 AM, Brad King  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@SIMULATE_ID \"MSVC\"
> +# elif defined(__GNUC__)
> +#  define @PREFIX@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
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-08-04 Thread Brad King 
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@SIMULATE_ID \"MSVC\"
+# elif defined(__GNUC__)
+#  define @PREFIX@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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-08-03 Thread Chaoren Lin via cmake-developers 
> 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.

On Wed, Aug 3, 2016 at 5:56 AM, Brad King  wrote:

> On 08/02/2016 06:59 PM, Chaoren Lin wrote:
> >> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> >> should be detected as GNU and cause the existing code to work.
> >
> > Huh, it doesn't look like that variable is set automatically when using
> > clang with the gcc toolchain. Is that supposed to happen?
> > It should be set manually (say, in a toolchain file)?
>
> It is supposed to be detected automatically.  Whenever Clang is detected
> on Windows the _SIMULATE_ID should be detected too.  I found the problem.
> The simulate id detection is done here:
>
>
> https://gitlab.kitware.com/cmake/cmake/blob/v3.6.1/Modules/Compiler/Clang-DetermineCompilerInternal.cmake#L12-15
>
> and it only looks for MSVC.  Grepping for SIMULATE_ID reveals that it is
> used for Intel and Clang but only ever detects when MSVC is simulated.
> All consuming code paths are interested in whether SIMULATE_ID==MSVC
> and otherwise assume GNU, except cmGlobalNinjaGenerator::EnableLanguage.
>
> It will take some investigation to decide how/whether to set SIMULATE_ID
> to GNU.  Alternatively the corresponding test in the Ninja generator could
> be changed to look for `COMPILER_ID == Clang && SIMULATE_ID != MSVC`.
>
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-08-03 Thread Brad King 
On 08/02/2016 06:59 PM, Chaoren Lin wrote:
>> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
>> should be detected as GNU and cause the existing code to work.
> 
> Huh, it doesn't look like that variable is set automatically when using
> clang with the gcc toolchain. Is that supposed to happen?
> It should be set manually (say, in a toolchain file)?

It is supposed to be detected automatically.  Whenever Clang is detected
on Windows the _SIMULATE_ID should be detected too.  I found the problem.
The simulate id detection is done here:

  
https://gitlab.kitware.com/cmake/cmake/blob/v3.6.1/Modules/Compiler/Clang-DetermineCompilerInternal.cmake#L12-15

and it only looks for MSVC.  Grepping for SIMULATE_ID reveals that it is
used for Intel and Clang but only ever detects when MSVC is simulated.
All consuming code paths are interested in whether SIMULATE_ID==MSVC
and otherwise assume GNU, except cmGlobalNinjaGenerator::EnableLanguage.

It will take some investigation to decide how/whether to set SIMULATE_ID
to GNU.  Alternatively the corresponding test in the Ninja generator could
be changed to look for `COMPILER_ID == Clang && SIMULATE_ID != MSVC`.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-08-02 Thread Chaoren Lin via cmake-developers 
> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.

Huh, it doesn't look like that variable is set automatically when using
clang with the gcc toolchain. Is that supposed to happen?
It should be set manually (say, in a toolchain file)?

On Tue, Aug 2, 2016 at 10:08 AM, Brad King  wrote:

> On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> > Clang on Windows uses the GCC toolchain, so we need to avoid using
> > backslashes for paths in response files.
> [snip]
> >strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0
> ||
> >strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") ==
> 0 ||
> >strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0
> ||
> > -  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") ==
> 0) {
>
> Clang on Windows also comes in a cl-like variant whose response files may
> need backslashes.  In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.  What goes
> wrong in your use case?
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-08-02 Thread Brad King 
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> Clang on Windows uses the GCC toolchain, so we need to avoid using
> backslashes for paths in response files.
[snip]
>strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
>strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 ||
>strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 ||
> -  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) {

Clang on Windows also comes in a cl-like variant whose response files may
need backslashes.  In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
should be detected as GNU and cause the existing code to work.  What goes
wrong in your use case?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

2016-07-29 Thread Chaoren Lin via cmake-developers 
Clang on Windows uses the GCC toolchain, so we need to avoid using
backslashes for paths in response files.
---
 Source/cmGlobalNinjaGenerator.cxx | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Source/cmGlobalNinjaGenerator.cxx 
b/Source/cmGlobalNinjaGenerator.cxx
index 51175c7..776a44f 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -558,7 +558,12 @@ void cmGlobalNinjaGenerator::EnableLanguage(
   strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
   strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 ||
   strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 ||
-  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) {
+  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0 ||
+  // Clang uses the GCC toolchain.
+  strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "Clang") == 0 ||
+  strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "Clang") == 0 ||
+  strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "Clang") == 0 ||
+  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "Clang") == 0) {
 this->UsingGCCOnWindows = true;
   }
 #endif
-- 
2.8.0.rc3.226.g39d4020

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers