Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
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
[cmake-developers] [PATCH] bash-completion: Fix cmake -E lookup
Hi,
Please find attached a fix for the completion of the '-E' option.
The 'sed' match was not strong enough and took into account the wrapped
description text of long commands. This should now be fixed.
Regards,
Sylvain
>From e6312fb56b04ec653fd314df77881b38c1ff7dd0 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert
Date: Thu, 4 Aug 2016 18:59:21 +0200
Subject: [PATCH] bash-completion: Fix cmake -E lookup
In case of long ' ' the description text is wrapped
and indented on the next line.
Avoid taking these lines into account by explicitly requiring the third
character to be a non-space.
---
Auxiliary/bash-completion/cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 6061129..0a862fa 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -102,7 +102,7 @@ _cmake()
;;
-E)
COMPREPLY=( $( compgen -W "$( cmake -E help |& sed -n \
-'/^ /{s|^ \([^ ]\{1,\}\) .*$|\1|;p}' 2>/dev/null )" \
+'/^ [^ ]/{s|^ \([^ ]\{1,\}\) .*$|\1|;p}' 2>/dev/null )" \
-- "$cur" ) )
return
;;
--
2.8.1
--
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] [Review Request] Doxygen alive, but limping
Hello dear CMake developers! Changes there: https://gitlab.kitware.com/cmake/cmake/merge_requests/58 -- Revive Doxygen documentation as CMake Developer Reference. This is a complete change from the point of view of the installation process. I expect that after the publication of the contents will be improved. You can preview this changes from 'CMake Master' by me. Linux: http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Windows: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe -- Regards, Konstantin Podsvirov -- 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] cmake -E capabilities [attempt 2]
On 08/03/2016 09:52 AM, Brad King wrote: > I've revised Tobias's commits to rename NewFactory to GetFactory and > explain some rationale in the commit message: > > Refactor extra generator registration to use factories > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a354f60c > > Report more information about extra generators in generator factories > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd52a225 [snip] On 08/02/2016 02:30 PM, Brad King wrote: > > Once that tests cleanly I'll merge it to `master` and then we can > rebase the remaining changes on it. The above commits are now in `master`. Please rebase the rest of the topic. Please update Help/manual/cmake.1.rst to document the `-E capabilities` option. Also please add a case to Tests/RunCMake/CommandLine/RunCMakeTest.cmake to at least run `cmake -E capabilities` as a smoke test. Is there a JSON convention for documenting schema? We will need to be able to document the capabilities output format as well as the protocol formats of cmake server mode. 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.
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
