[cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison
This silents possible CMP0054 related warnings.
---
Modules/FindCUDA.cmake | 14 +++---
Modules/FindCUDA/run_nvcc.cmake | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 9348aa5..2e2b21c 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources
_cmake_options _options)
set( ${_options} )
set( _found_options FALSE )
foreach(arg ${ARGN})
-if(arg STREQUAL OPTIONS)
+if(x${arg} STREQUAL xOPTIONS)
set( _found_options TRUE )
elseif(
-arg STREQUAL WIN32 OR
-arg STREQUAL MACOSX_BUNDLE OR
-arg STREQUAL EXCLUDE_FROM_ALL OR
-arg STREQUAL STATIC OR
-arg STREQUAL SHARED OR
-arg STREQUAL MODULE
+x${arg} STREQUAL xWIN32 OR
+x${arg} STREQUAL xMACOSX_BUNDLE OR
+x${arg} STREQUAL xEXCLUDE_FROM_ALL OR
+x${arg} STREQUAL xSTATIC OR
+x${arg} STREQUAL xSHARED OR
+x${arg} STREQUAL xMODULE
)
list(APPEND ${_cmake_options} ${arg})
else()
diff --git a/Modules/FindCUDA/run_nvcc.cmake b/Modules/FindCUDA/run_nvcc.cmake
index 58e0d31..abdd307 100644
--- a/Modules/FindCUDA/run_nvcc.cmake
+++ b/Modules/FindCUDA/run_nvcc.cmake
@@ -126,7 +126,7 @@ endif()
# and other return variables are present after executing the process.
macro(cuda_execute_process status command)
set(_command ${command})
- if(NOT _command STREQUAL COMMAND)
+ if(NOT x${_command} STREQUAL xCOMMAND)
message(FATAL_ERROR Malformed call to cuda_execute_process. Missing
COMMAND as second argument. (command = ${command}))
endif()
if(verbose)
--
1.9.3 (Apple Git-50)
--
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] Nice DMG layout for CMake OSX builds
This looks amazing, thanks for the work. On Tue, Sep 16, 2014 at 7:10 PM, Adam Strzelecki o...@java.pl wrote: Hi, I've made simple background: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif And together with my shell script for creating dmg with custom layout at: https://gist.github.com/nanoant/89237ad368d333795fc0 I have created installer that looks like that: So feel free to take modify script above and TIFF file. Cheers, -- Adam -- 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 -- 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] FindCUDA: Wrap keyword in if() string comparison
Wait, what? This is actually the opposite of what that policy is for, no? Adam, I don't blame you, just to get that said first. The question is: does this policy warning trigger far too often? Yes, you are absolutely right. But the problem is that internal modules run in whatever policy is currently set. Few of them conditionally change policy for some short scopes. I was more less following how Brad has been fixing this issues on other modules, i.e.: e177e7affb10fc25b71d4c9d9796c9df7fcdb800 Honestly I would expect that all internal modules run in latest policy by default, or at least declare their policy in file header, but this is not a case. --Adam -- 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] FindCUDA: Wrap keyword in if() string comparison
On 17.09.2014 14:48, Nils Gladitz wrote: Maybe modules loaded from the cmake installation itself should implicitly have their policy version set to the current cmake version? I pushed root-modules-set-policies-new to stage which sets all policies to NEW for modules from cmake's own Modules directory if NO_POLICY_SCOPE is not used. I haven't merged it to next yet in case someone things this is the wrong thing to do in general. I figured since the new behavior only applies to cmake's own modules it should not require a policy. Nils -- 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 3/6] Resolve replace @rpath placeholders
On Wednesday, September 17, 2014 01:13:45 AM Adam Strzelecki wrote: What is the new optional parameter to gp_file_type() used for? My intention was to pass exepath rather than take it from the path of original_file. But this is in fact not necessary. I don't see any code in your branch calling that function with the new parameter. You are right, I am not using that. So I can drop that change. --Adam After that change is dropped, I give a +1 for the patch set. Thanks, Clint -- 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] [CMake 0015162]: FindGettext.cmake documentation issue
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15162 == Reported By:vollmond Assigned To: == Project:CMake Issue ID: 15162 Category: CMake Reproducibility:always Severity: trivial Priority: low Status: new == Date Submitted: 2014-09-18 00:55 EDT Last Modified: 2014-09-18 00:55 EDT == Summary:FindGettext.cmake documentation issue Description: GETTEXT_PROCESS_POT = GETTEXT_PROCESS_POT_FILE == Issue History Date ModifiedUsername FieldChange == 2014-09-18 00:55 vollmond New Issue 2014-09-18 00:55 vollmond File Added: FindGettext.cmake.patch == -- 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] [Cdash] Show results from the bullseye coverage in CDash
Sorry for the long response time but we are currently in a release stage. No, the submit seems fine, but the value in the Coverage.xml looks like PercentCoverage0.00/PercentCoverage ElapsedMinutes0.00/ElapsedMinutes Which can't be. However, the *-covbr.* and *-covsrc.* are generated with valid values. Currently CMake 3.0.1 and CDash 2.2.2 are used Best Regards Am 05.09.2014 um 12:45 schrieb David Cole dlrd...@aol.com: When the coverage shows 0% is there any indication that the ctest_submit for the coverage step failed? (i.e. do you log the output of ctest, and does it show anything about failing to submit?) That's another type of intermittent network blip that I see, where there's a successful local build, but the submit of a piece of the dashboard fails occasionally. D -- 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
Re: [CMake] [Cdash] Show results from the bullseye coverage in CDash
No, the submit seems fine, but the value in the Coverage.xml looks like PercentCoverage0.00/PercentCoverage ElapsedMinutes0.00/ElapsedMinutes Which can't be. However, the *-covbr.* and *-covsrc.* are generated with valid values. Sounds like a bug in ctest then. There must be something going wrong in the code that reads the coverage files and generates Coverage.xml. Can you reproduce the problem with a minimal test case? Or debug it yourself to analyze what's going wrong with ctest on the machine demonstrating the problem? Thanks, David C. -- 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
[CMake] TARGET_LINK_LIBRARIES with full path libraries
I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces /path/to/libXXX.so by -lXXX. The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES. In particular CMakeLists.txt reads: SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++) CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(XXX) add_executable(xxx xxx.cpp) target_link_libraries(xxx /opt/XXX/lib/libXXX.so) When running make VERBOSE=1 produces output like /opt/XXX/bin/g++ (...) -lXXX which is not the same as /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so I am wondering if this is a cmake bug and if there exists a workaround. -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On 09/17/2014 12:29 PM, Volker Pilipp wrote: I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces /path/to/libXXX.so by -lXXX. The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES. In particular CMakeLists.txt reads: SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++) CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(XXX) add_executable(xxx xxx.cpp) target_link_libraries(xxx /opt/XXX/lib/libXXX.so) When running make VERBOSE=1 produces output like /opt/XXX/bin/g++ (...) -lXXX which is not the same as /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so I think CMake reverts to linking by name if either the library is in an implicit linker directory (e.g. a directory the linker searches by default) or if the shared library does not have an SONAME. Which library does -lXXX resolve to? e.g. why aren't the two command lines equivalent for you? Specifically which library does the linker (ld) pick up; not the runtime loader (ld.so). Nils -- 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
Re: [CMake] [Cdash] Show results from the bullseye coverage in CDash
Am 17.09.2014 12:02, schrieb David Cole via CMake: No, the submit seems fine, but the value in the Coverage.xml looks like PercentCoverage0.00/PercentCoverage ElapsedMinutes0.00/ElapsedMinutes Which can't be. However, the *-covbr.* and *-covsrc.* are generated with valid values. Sounds like a bug in ctest then. There must be something going wrong in the code that reads the coverage files and generates Coverage.xml. Can you reproduce the problem with a minimal test case? Or debug it yourself to analyze what's going wrong with ctest on the machine demonstrating the problem? Excellent would be if you could provide an output file of Bullseye that shows that problem that could later be used in an automated test, the code parsing Bullseye data is currently not tested at all. Ideally you would use Bullseye to analyze either a dummy file or something from CMake itself so you do not need to show anything of your code (and CMake doesn't need to ship that). Greetings, Eike -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On Wed, Sep 17, 2014 at 12:58 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 12:29 PM, Volker Pilipp wrote: I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces /path/to/libXXX.so by -lXXX. The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES. In particular CMakeLists.txt reads: SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++) CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(XXX) add_executable(xxx xxx.cpp) target_link_libraries(xxx /opt/XXX/lib/libXXX.so) When running make VERBOSE=1 produces output like /opt/XXX/bin/g++ (...) -lXXX which is not the same as /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so I think CMake reverts to linking by name if either the library is in an implicit linker directory (e.g. a directory the linker searches by default) or if the shared library does not have an SONAME. Which library does -lXXX resolve to? e.g. why aren't the two command lines equivalent for you? -lXXX stands in the actual case for libcurl.so. I have both /usr/lib4/libcurl.so.3 and /opt/XXX/llib/libcurl.so.4 installed and I want my program to be linked against the latter one. Specifically which library does the linker (ld) pick up; not the runtime loader (ld.so). An ldd on the executable produces libcurl.so.3 = /usr/lib64/libcurl.so.3 Depending on LD_LIBRARY_PATH, (or rpath,...) I would have expected something like this libcurl.so.4 = NOT FOUND or libcurl.so.4 = /opt/XXX/lib/libcurl.so.4 Volker -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
can't just add link_directories( /opt/XXX/lib ) ? On Wed, Sep 17, 2014 at 3:58 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 12:29 PM, Volker Pilipp wrote: I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces /path/to/libXXX.so by -lXXX. The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES. In particular CMakeLists.txt reads: SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++) CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(XXX) add_executable(xxx xxx.cpp) target_link_libraries(xxx /opt/XXX/lib/libXXX.so) When running make VERBOSE=1 produces output like /opt/XXX/bin/g++ (...) -lXXX which is not the same as /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so I think CMake reverts to linking by name if either the library is in an implicit linker directory (e.g. a directory the linker searches by default) or if the shared library does not have an SONAME. Which library does -lXXX resolve to? e.g. why aren't the two command lines equivalent for you? Specifically which library does the linker (ld) pick up; not the runtime loader (ld.so). Nils -- 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 -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) - no effect but link_directories( /opt/ ) - -L/opt (?!) Volker On Wed, Sep 17, 2014 at 1:32 PM, J Decker d3c...@gmail.com wrote: can't just add link_directories( /opt/XXX/lib ) ? On Wed, Sep 17, 2014 at 3:58 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 12:29 PM, Volker Pilipp wrote: I have encountered the following problem with cmake 3.0.1. Under certain circumstances TARGET_LINK_LIBRARIES replaces /path/to/libXXX.so by -lXXX. The problem occurred when I used a non-standard compiler at /opt/XXX/bin/g++ and added the library /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES. In particular CMakeLists.txt reads: SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++) CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0) PROJECT(XXX) add_executable(xxx xxx.cpp) target_link_libraries(xxx /opt/XXX/lib/libXXX.so) When running make VERBOSE=1 produces output like /opt/XXX/bin/g++ (...) -lXXX which is not the same as /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so I think CMake reverts to linking by name if either the library is in an implicit linker directory (e.g. a directory the linker searches by default) or if the shared library does not have an SONAME. Which library does -lXXX resolve to? e.g. why aren't the two command lines equivalent for you? Specifically which library does the linker (ld) pick up; not the runtime loader (ld.so). Nils -- 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 -- ** Volker Pilipp Software IT Technologies DECTRIS Ltd. Neuenhoferstr. 107 5400 Baden Switzerland +41 56 500 2100 general +41 56 500 2101 fax +41 56 500 2115 direct volker.pil...@dectris.com www.dectris.com ** Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited. -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On 09/17/2014 01:50 PM, Volker Pilipp wrote: I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) - no effect but link_directories( /opt/ ) - -L/opt (?!) Probably the same logic as for target_link_libraries(). E.g. implicit link directories aren't repeated as explicit link directories. Nils -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On Wed, Sep 17, 2014 at 2:04 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 01:50 PM, Volker Pilipp wrote: I did so and found the following strange behaviour link_directories( /opt/XXX/lib ) - no effect but link_directories( /opt/ ) - -L/opt (?!) Probably the same logic as for target_link_libraries(). E.g. implicit link directories aren't repeated as explicit link directories. But it is not an implicit link directory at least not according to the output of /sbin/ldconfig -p . What does cmake consider an implicit link directory? Volker Nils -- ** Volker Pilipp Software IT Technologies DECTRIS Ltd. Neuenhoferstr. 107 5400 Baden Switzerland +41 56 500 2100 general +41 56 500 2101 fax +41 56 500 2115 direct volker.pil...@dectris.com www.dectris.com ** Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited. -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On 09/17/2014 02:17 PM, Volker Pilipp wrote:
On Wed, Sep 17, 2014 at 2:04 PM, Nils Gladitz nilsglad...@gmail.com
mailto:nilsglad...@gmail.com wrote:
On 09/17/2014 01:50 PM, Volker Pilipp wrote:
I did so and found the following strange behaviour
link_directories( /opt/XXX/lib ) - no effect
but
link_directories( /opt/ ) - -L/opt (?!)
Probably the same logic as for target_link_libraries().
E.g. implicit link directories aren't repeated as explicit link
directories.
But it is not an implicit link directory at least not according to the
output of
/sbin/ldconfig -p . What does cmake consider an implicit link directory?
I think a directory in which the linker looks by default (not the
runtime loader; which is what ldconfig manages).
Run e.g.
echo int main() {}|/opt/XXX/bin/g++ -xc++ - -v
And see the directories being passed to collect2 with -L.
Nils
--
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
Re: [CMake] Code Coverage Bullseye
I am trying to configure the code coverage using the ctest script. I took help from : http://www.cmake.org/Wiki/CTest/Coverage That wiki page was mostly written in 2007 and 2009. You may want to refer to something more recent than that, and something that's proven to work, like an existing dashboard script that does coverage, as a reference. One thing to note: there may not be a working example of somebody doing code coverage using the Xcode generator on a Mac. If there is, hopefully he will speak up here, and give you some additional hints. You might have better luck doing a coverage dashboard on Linux using gcc and gcov. See the scripts used for coverage dashboards on the CMake dashboard... for example, this one: http://open.cdash.org/viewNotes.php?buildid=3493343 Especially note the use of the -fprofile-arcs -ftest-coverage flags in the script. (Mentioned on that wiki page, I might add.) Is Bullseye is mandatory for code coverage using ctest ??? Is there any way to perform code coverage through ctest without using bullseye ?? Bullseye is absolutely NOT mandatory for code coverage testing using ctest, it's simply one of the available options. If you do not have Bullseye, there is no need to set the COVFILE env variable. HTH, David C. -- 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
Re: [CMake] Code Coverage Bullseye
Hello, since code coverage doesn't work very well with gcov and so on on Mac, our company decided to use bullseye for Mac OS too. I hope it helps Am 17.09.2014 um 14:22 schrieb David Cole via CMake cmake@cmake.org: I am trying to configure the code coverage using the ctest script. I took help from : http://www.cmake.org/Wiki/CTest/Coverage That wiki page was mostly written in 2007 and 2009. You may want to refer to something more recent than that, and something that's proven to work, like an existing dashboard script that does coverage, as a reference. One thing to note: there may not be a working example of somebody doing code coverage using the Xcode generator on a Mac. If there is, hopefully he will speak up here, and give you some additional hints. You might have better luck doing a coverage dashboard on Linux using gcc and gcov. See the scripts used for coverage dashboards on the CMake dashboard... for example, this one: http://open.cdash.org/viewNotes.php?buildid=3493343 Especially note the use of the -fprofile-arcs -ftest-coverage flags in the script. (Mentioned on that wiki page, I might add.) Is Bullseye is mandatory for code coverage using ctest ??? Is there any way to perform code coverage through ctest without using bullseye ?? Bullseye is absolutely NOT mandatory for code coverage testing using ctest, it's simply one of the available options. If you do not have Bullseye, there is no need to set the COVFILE env variable. HTH, David C. -- 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 -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
Run e.g.
echo int main() {}|/opt/XXX/bin/g++ -xc++ - -v
The output is
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/opt/XXX
Thread model: posix
gcc version 4.8.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/opt/XXX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/cc1plus -quiet -v
-D_GNU_SOURCE - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase -
-version -o /tmp/ccXHzSkQ.s
GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 4.3.2, MPFR version
2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2/x86_64-unknown-linux-gnu
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2/backward
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include
/usr/local/include
/opt/XXX/include
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 4.3.2, MPFR version
2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d8088594c0e624acf8c1ee4300a343b6
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccytHs8u.o /tmp/ccXHzSkQ.s
GNU assembler version 2.17.50.0.6-26.el5 (x86_64-redhat-linux) using BFD
version 2.17.50.0.6-26.el5 20061020
COMPILER_PATH=/opt/XXX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/libexec/gcc/x86_64-unknown-linux-gnu/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/opt/XXX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbegin.o
-L/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
-L/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. /tmp/ccytHs8u.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtend.o
/usr/lib/../lib64/crtn.o
I suppose it is the line
LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/usr/lib/
I see that /usr/lib64 (where libcurl.so.3 resides) is before /opt/XXX/lib
(where libcurl.so.4 resides). That's why g++ links against the wrong
library. However, this problem would not occur if I could stop cmake from
replacing /opt/XXX/lib/libcurl.so by -lcurl :-(
Volker
--
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
Re: [CMake] Code Coverage Bullseye
On 9/17/2014 8:47 AM, NoRulez wrote: Hello, since code coverage doesn't work very well with gcov and so on on Mac, our company decided to use bullseye for Mac OS too. If you could email the COVFILE to me I could take a look. Also it might help if you could run ctest with --debug and -VV and send those results to me as well. Sounds like and issue with ctest. -Bill -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On 09/17/2014 02:50 PM, Volker Pilipp wrote: I see that /usr/lib64 (where libcurl.so.3 resides) is before /opt/XXX/lib (where libcurl.so.4 resides). That's why g++ links against the wrong library. However, this problem would not occur if I could stop cmake from replacing /opt/XXX/lib/libcurl.so by -lcurl :-( Maybe you could bring this up on the issue tracker: http://public.kitware.com/Bug/my_view_page.php I am not entirely sure what the proper thing to do would be. Nils -- 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
Re: [CMake] Get Visual Studio target Arch
No CMake time decisions are possible based on the configuration
I have a project that uses some unix libraries. I use find_package() to
locate them. On Windows platform find_package() obviously fails so I
maintain folder with prebuilt binaries. So my CMakeLists.txt looks like:
if (${CMAKE_SYSTEM_NAME} MATCHES Windows)
set(CMAKE_LIBRARY_PATH win32/x86/lib)
endif()
find_package(A REQUIRED)
find_package(B REQUIRED)
find_package(C REQUIRED)
Now I want to add x64 build support. Obviously now it fails when tries to
link x64 binary to x86 prebuilt libs. I cant use CMAKE_SYSTEM_PROCESSOR
because its always defined to AMD64. Also I cant use VS $(Platform)
variable because find_package() runs at cmake time. So how I should
handle it without cmake time decisions? Use internal undocumented
MSVC_C_ARCHITECTURE_ID?
Use CMAKE_CL_64\CMAKE_FORCE_WIN64\CMAKE_FORCE_IA64 vars that are x64-only
hack that will fail for ARM build? Use CMAKE_GENERATOR var and find
Win64\ARM substrings in it?
I'm really running out of ideas and will appreciate any help in this
question.
Regards, Alexey
On Wed, Sep 17, 2014 at 2:35 AM, Gilles Khouzam
gilles.khou...@microsoft.com wrote:
Hi David, Alexey
I'm glad to hear your enthusiasm about our involvement with CMake. We're
still trying to understand the issues that people are facing and how we can
help improve those. The multi-platform support is something somewhat
experimental that will have issues, but getting feedback will help address
the issues that you might run into.
Alexey, the issue with CMAKE_SYSTEM_PROCESSOR seems to come from the
CMakeDetermineSystem.cmake (lines 110 and below) file which only sets it
for WINCE based on the MSVC_C_ARCHITECTURE_ID and uses the HOST processor
otherwise. That's probably why you're seeing AMD64 all the time. My initial
thought is that using MSVC_C_ARCHITECTURE_ID should give you at least the
right processor for the compile.
BTW, I've only enabled the multiplatform support for cross-compiling for
Windows Phone and Windows Store apps (to reduce the potential regressions)
but if you would like to have it for native Windows apps, I should be able
to easily enable it.
Looking forward to being able to help more.
Gilles Khouzam
Senior Development Lead
Microsoft OSG
-Original Message-
From: David Cole [mailto:dlrd...@aol.com]
Sent: Tuesday, September 16, 2014 03:37
To: alexey.petruc...@gmail.com; Gilles Khouzam
Cc: cmake@cmake.org
Subject: Re: [CMake] Get Visual Studio target Arch
I still cant really make some arch specific ifdefs in my cmake scripts
using this approach.
That's the point of a multi-configuration, multi-architecture Visual
Studio solution: you defer choosing the configuration *and* the
architecture until build time.
No CMake time decisions are possible based on the configuration or the
architecture with this approach because neither is known until compile time.
It is inappropriate to choose the configuration or architecture in CMake
code with this approach, and you should re-think about it and see if you
can make compile time decisions instead, possibly with #ifdef sections in
your C/C++ code...
Rather than re-organize your libraries, you could easily just use
win32/libs/$(Platform) as your value when using the VS generators, and
this should work.
By the way, Gilles, I echo the sentiment: nice work! I wish MS had gotten
involved in CMake even earlier... but welcome!
HTH,
David C.
--
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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote: ... I suppose it is the line LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib /../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/ usr/lib/ yes, cmake checks $LIBRARY_PATH and uses -l for the libraries located in these directories. I stumbled about that behaviour last year or so, I guess it's a feature. Alex -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
Would it be possible to set something like: TARGET_LINK_LIBRARIES(myexe -L/opt/XXX/lib -lcurl) in the path? On Wed, Sep 17, 2014 at 9:33 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 02:50 PM, Volker Pilipp wrote: I see that /usr/lib64 (where libcurl.so.3 resides) is before /opt/XXX/lib (where libcurl.so.4 resides). That's why g++ links against the wrong library. However, this problem would not occur if I could stop cmake from replacing /opt/XXX/lib/libcurl.so by -lcurl :-( Maybe you could bring this up on the issue tracker: http://public.kitware.com/Bug/my_view_page.php I am not entirely sure what the proper thing to do would be. Nils -- 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 -- 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
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
That actually does the trick. But it's not nice, because there are many targets in the project. Actually, I do not know about any use case, where cmake should replace a full path to a lib by its -l shortcut. Thank you very much for your help. Volker On Wed, Sep 17, 2014 at 10:40 PM, j s j.s4...@gmail.com wrote: Would it be possible to set something like: TARGET_LINK_LIBRARIES(myexe -L/opt/XXX/lib -lcurl) in the path? On Wed, Sep 17, 2014 at 9:33 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/17/2014 02:50 PM, Volker Pilipp wrote: I see that /usr/lib64 (where libcurl.so.3 resides) is before /opt/XXX/lib (where libcurl.so.4 resides). That's why g++ links against the wrong library. However, this problem would not occur if I could stop cmake from replacing /opt/XXX/lib/libcurl.so by -lcurl :-( Maybe you could bring this up on the issue tracker: http://public.kitware.com/Bug/my_view_page.php I am not entirely sure what the proper thing to do would be. Nils -- 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 -- 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
[Cmake-commits] CMake branch, next, updated. v3.0.2-5358-ge1dc2e3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via e1dc2e3050c1c61489ccff85479d03f81a98c084 (commit)
via 7bddcf337c145819774be52456e6c5c30756c002 (commit)
via b8877b1d62599bba7a014e95fbbd670f177243ce (commit)
from 240356877edd2ec55024b51bd0b862fcef002ee1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1dc2e3050c1c61489ccff85479d03f81a98c084
commit e1dc2e3050c1c61489ccff85479d03f81a98c084
Merge: 2403568 7bddcf3
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Sep 17 08:51:07 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Sep 17 08:51:07 2014 -0400
Merge topic 'autogen-fixes' into next
7bddcf33 QtAutogen: Process all ui files in a source file (#14981).
b8877b1d QtAutogen: Add source files to target when only AUTORCC is used.
diff --cc Tests/QtAutogen/CMakeLists.txt
index 3973653,f1a272a..3fd00b8
--- a/Tests/QtAutogen/CMakeLists.txt
+++ b/Tests/QtAutogen/CMakeLists.txt
@@@ -64,15 -67,10 +67,16 @@@ add_custom_command
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/myotherinterface.h.in
)
+message(CMAKE_BUILD_TYPE = ${CMAKE_BUILD_TYPE})
+if (CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg] AND NOT
CMAKE_CONFIGURATION_TYPES)
+ set(debug_srcs $$CONFIG:Debug:debug_class.cpp
$$CONFIG:Debug:debug_resource.qrc)
+ add_definitions(-DTEST_DEBUG_CLASS)
+endif()
+
add_executable(QtAutogen main.cpp calwidget.cpp second_widget.cpp foo.cpp
blub.cpp bar.cpp abc.cpp
+multiplewidgets.cpp
xyz.cpp yaf.cpp gadget.cpp $TARGET_OBJECTS:privateSlot
- test.qrc second_resource.qrc resourcetester.cpp generated.cpp
+ test.qrc second_resource.qrc resourcetester.cpp generated.cpp
${debug_srcs}
)
set_property(TARGET QtAutogen APPEND PROPERTY AUTOGEN_TARGET_DEPENDS
generate_moc_input ${CMAKE_CURRENT_BINARY_DIR}/myotherinterface.h)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7bddcf337c145819774be52456e6c5c30756c002
commit 7bddcf337c145819774be52456e6c5c30756c002
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Sep 17 01:23:57 2014 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Sep 17 14:51:03 2014 +0200
QtAutogen: Process all ui files in a source file (#14981).
Use a vector to store a list of matched ui_ includes, instead of
overwriting the previous match.
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 4b8f810..9c5d846 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -1296,8 +1296,8 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
const std::vectorstd::string headerExtensions =
makefile-GetHeaderExtensions();
- std::mapstd::string, std::string includedUis;
- std::mapstd::string, std::string skippedUis;
+ std::mapstd::string, std::vectorstd::string includedUis;
+ std::mapstd::string, std::vectorstd::string skippedUis;
std::vectorstd::string uicSkipped;
cmSystemTools::ExpandListArgument(this-SkipUic, uicSkipped);
@@ -1307,7 +1307,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
{
const bool skipUic = std::find(uicSkipped.begin(), uicSkipped.end(), *it)
!= uicSkipped.end();
-std::mapstd::string, std::string uiFiles
+std::mapstd::string, std::vectorstd::string uiFiles
= skipUic ? skippedUis : includedUis;
const std::string absFilename = *it;
if (this-Verbose)
@@ -1368,12 +1368,17 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile*
makefile)
{
this-GenerateMoc(it-first, it-second);
}
- for(std::mapstd::string, std::string::const_iterator
+ for(std::mapstd::string, std::vectorstd::string ::const_iterator
it = includedUis.begin();
it != includedUis.end();
++it)
{
-this-GenerateUi(it-first, it-second);
+for (std::vectorstd::string::const_iterator nit = it-second.begin();
+nit != it-second.end();
+++nit)
+ {
+ this-GenerateUi(it-first, *nit);
+ }
}
if(!this-RccExecutable.empty())
@@ -1450,7 +1455,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
void cmQtAutoGenerators::ParseCppFile(const std::string absFilename,
const std::vectorstd::string headerExtensions,
std::mapstd::string, std::string includedMocs,
- std::mapstd::string, std::string includedUis)
+ std::mapstd::string,
[Cmake-commits] CMake branch, next, updated. v3.0.2-5361-gd86565b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via d86565b9d0f0577bcf3428a74552001ca6f7534c (commit) via 49b8140e5db355229dd2984967e8a08713c9ea9b (commit) via 0b80fc350ae71f0926b426762cb1f6efe17a5723 (commit) from e1dc2e3050c1c61489ccff85479d03f81a98c084 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d86565b9d0f0577bcf3428a74552001ca6f7534c commit d86565b9d0f0577bcf3428a74552001ca6f7534c Merge: e1dc2e3 49b8140 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Sep 17 08:58:15 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Sep 17 08:58:15 2014 -0400 Merge topic 'clang-compile-options-cxx14' into next 49b8140e Clang: Enable c++14 dialect flag with Clang 3.5. 0b80fc35 Clang: Don't overwrite c++11 compile option value with c++14 flag. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49b8140e5db355229dd2984967e8a08713c9ea9b commit 49b8140e5db355229dd2984967e8a08713c9ea9b Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Sep 17 14:57:07 2014 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Sep 17 14:57:07 2014 +0200 Clang: Enable c++14 dialect flag with Clang 3.5. diff --git a/Modules/Compiler/Clang-CXX.cmake b/Modules/Compiler/Clang-CXX.cmake index 7792999..5dd7b4a 100644 --- a/Modules/Compiler/Clang-CXX.cmake +++ b/Modules/Compiler/Clang-CXX.cmake @@ -23,7 +23,10 @@ elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 2.1) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++0x) endif() -if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.4) +if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.5) + set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14) + set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++14) +elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.4) set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y) set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++1y) endif() http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b80fc350ae71f0926b426762cb1f6efe17a5723 commit 0b80fc350ae71f0926b426762cb1f6efe17a5723 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Sep 17 14:56:16 2014 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Sep 17 14:56:16 2014 +0200 Clang: Don't overwrite c++11 compile option value with c++14 flag. diff --git a/Modules/Compiler/Clang-CXX.cmake b/Modules/Compiler/Clang-CXX.cmake index bdb6d69..7792999 100644 --- a/Modules/Compiler/Clang-CXX.cmake +++ b/Modules/Compiler/Clang-CXX.cmake @@ -24,8 +24,8 @@ elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 2.1) endif() if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.4) - set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++1y) - set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++1y) + set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y) + set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++1y) endif() set(CMAKE_CXX_STANDARD_DEFAULT 98) --- Summary of changes: Modules/Compiler/Clang-CXX.cmake |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.2-5364-ga1bf041
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a1bf041d167b621ae46f4f27b71ab0801947abbe (commit)
via 80bda1684d48b19a05637fe4167b5f9b1fd8ce2d (commit)
via 1927e4bacb8e3183488c0e71a18b73aa62e5f53a (commit)
from d86565b9d0f0577bcf3428a74552001ca6f7534c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a1bf041d167b621ae46f4f27b71ab0801947abbe
commit a1bf041d167b621ae46f4f27b71ab0801947abbe
Merge: d86565b 80bda16
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Sep 17 09:11:46 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Sep 17 09:11:46 2014 -0400
Merge topic 'minor-cleanups' into next
80bda168 Simplify use of binary_search.
1927e4ba Remove const char string comparison helper.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80bda1684d48b19a05637fe4167b5f9b1fd8ce2d
commit 80bda1684d48b19a05637fe4167b5f9b1fd8ce2d
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Aug 6 15:20:24 2014 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Sep 17 15:10:55 2014 +0200
Simplify use of binary_search.
A local string was created when dir was a const char*. Now dir is a
std::string already so the dirString is vestigal.
diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index 9a42ca2..14b5a92 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -519,9 +519,7 @@ bool cmGeneratorTarget::IsSystemIncludeDirectory(const
std::string dir,
iter = this-SystemIncludesCache.insert(entry).first;
}
- std::string dirString = dir;
- return std::binary_search(iter-second.begin(), iter-second.end(),
-dirString);
+ return std::binary_search(iter-second.begin(), iter-second.end(), dir);
}
//
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1927e4bacb8e3183488c0e71a18b73aa62e5f53a
commit 1927e4bacb8e3183488c0e71a18b73aa62e5f53a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Sep 17 15:07:55 2014 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Sep 17 15:10:25 2014 +0200
Remove const char string comparison helper.
It is now unused.
diff --git a/Source/cmStandardIncludes.h b/Source/cmStandardIncludes.h
index 3731502..8baf7b3 100644
--- a/Source/cmStandardIncludes.h
+++ b/Source/cmStandardIncludes.h
@@ -462,12 +462,6 @@ struct cmStrCmp {
return strcmp(input, m_test.c_str()) == 0;
}
- // For use with binary_search
- bool operator()(const char *str1, const char *str2) const
- {
-return strcmp(str1, str2) 0;
- }
-
private:
const std::string m_test;
};
---
Summary of changes:
Source/cmGeneratorTarget.cxx |4 +---
Source/cmStandardIncludes.h |6 --
2 files changed, 1 insertion(+), 9 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.2-1874-g201cc6f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 201cc6fe095f1a0abfc34bb6482d933cc12ff055 (commit) from 7b11f87100f07d0c504da0720387f0c7f818fb3e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=201cc6fe095f1a0abfc34bb6482d933cc12ff055 commit 201cc6fe095f1a0abfc34bb6482d933cc12ff055 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Sep 18 00:01:09 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Sep 18 00:01:09 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 489f6d8..36c426d 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140917) +set(CMake_VERSION_PATCH 20140918) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
