Re: [cmake-developers] Debugger for CMake
+1 Wish this existed since forever. Cheers, Adam From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Justin Berger Sent: Monday, January 30, 2017 11:10 AM To: cmake-developers@cmake.org Subject: [cmake-developers] Debugger for CMake I've made a proof of concept for a debugger integrated into CMake. The code and notes about the implementation are here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/447 It is still a work in progress and there is still a decent chunk of work to be done. The general approach works though and seems sufficient. I'd like feedback on a few things: a) Is this feature worthwhile for eventual merge into CMake? b) Is there any functionality not addressed that would make this sort of tool more useful? c) What is the best approach to make this kind of feature appealing to IDE / UI tools which currently work with CMake? Have a good one, Justin -- 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_CXX_STANDARD seems to be ineffective
Hello all, I have switched my project over to using the CMAKE_CXX_STANDARD variable and it does not seem to be recognized by the ITK external project that I configure/build. Before I dive into too many details, is anyone familiar with any issues surrounding this variable? I currently have it set as a string variable with the value 11. 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
[cmake-developers] CMAKE_CXX_STANDARD seems to be ineffective (Ubuntu 14.04)
Hello all, I have switched my project over to using the CMAKE_CXX_STANDARD variable and it does not seem to be recognized by the ITK external project that I configure/build. The project does not build (ITK tag 4.10.0) with CMAKE_CXX_STANDARD:STRING=11, but does build with CMAKE_CXX_FLAGS:STRING="... -std=c++11" Before I dive into too many details, is anyone familiar with any issues surrounding this variable? 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
Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations
Ah, gotcha. So, is it expected that each project in a client's package will call find_package(xyz)? I am used to the top level CMakeLists finding all the dependencies, and then passing the information down into projects. I am happy to update our system behavior to match what is more correct. Adam -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, February 03, 2016 1:36 PM To: Adam Rankin Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations On 02/03/2016 01:03 PM, Adam Rankin wrote: > Is there documentation on best practices for writing findxyz modules? There is a section in the cmake-developer manual: https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules > How does a client determine the target names that are imported after > calling find_package? Client authors should read the module documentation, just as they might to see the list of provided variables. -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] [partial duplicate of users mailing list] SelectLibraryConfigurations
Ok, I admit I'm just diving into cmake internals so I'm still catching up. Is there documentation on best practices for writing findxyz modules? How does a client determine the target names that are imported after calling find_package? Thanks for the help, I'm happy to do my learning by reading if you have any recommended resources. Cheers, Adam > On Feb 3, 2016, at 12:54 PM, Brad King wrote: > >> On 02/03/2016 12:47 PM, Adam Rankin wrote: >> I am wondering if it should not be populating _LIBRARIES variable >> with target names? > > The _LIBRARIES variables are essentially the legacy interface to > modules that provide imported targets. Clients should choose to > use the imported targets explicitly. > > -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] [partial duplicate of users mailing list] SelectLibraryConfigurations
Hello all, I am exploring FindZLIB.cmake and FindPNG.cmake and they both use SelectLibraryConfigurations.cmake. The macro in this file populates xyz_LIBRARIES with library file locations. I am wondering if it should not be populating _LIBRARIES variable with target names? Can it even possibly resolve target names from library files? If not, should _LIBRARIES not be set by this macro? Thanks, 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
[cmake-developers] Patch for ExternalProject_Add git clone -o support
Hello all, As per my inquiry on the users mailing list, I have implemented support for the -origin parameter of git clone. It is backwards compatible as the parameter is optional and defaults to "origin". Example use case: After using ExternalProject_Add to download and built a supporting library, development of that library is needed. In the case of github/bitbucket, the cloned repository can be a fork. To simplify management, providing a more descriptive remote name is desired. Usage: ExternalProject_Add( OpenIGTLink "${PLUSBUILD_EXTERNAL_PROJECT_CUSTOM_COMMANDS}" SOURCE_DIR "${PLUS_OpenIGTLink_SRC_DIR}" BINARY_DIR "${PLUS_OpenIGTLink_DIR}" #--Download step-- GIT_REPOSITORY "${GIT_PROTOCOL}://github.com/adamrankin/OpenIGTLink.git" GIT_TAG "master" GIT_REMOTE_NAME "adamrankin_igtl" #--Configure step- ... I have attached a patch that provides an implementation of this parameter and tested it for both cloning and updating. Feedback is appreciated and I hope this is of use for others. Kind regards, Adam git_remote_name_support.patch Description: git_remote_name_support.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