[cmake-developers] CMake 3.9.3 available for download
We are pleased to announce that CMake 3.9.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.9.3 since 3.9.2: Brad King (3): VS: Do not consider MAP_IMPORTED_CONFIG_ on non-imported targets bootstrap: Fix running multiple times in-source CMake 3.9.3 Maarten de Vries (1): vim: Remove default setting of expandtab Roger Leigh (1): FindBoost: Add support for Boost 1.65.0 and 1.65.1 to CMake 3.9 Rolf Eike Beer (1): CTest: fix crash if source file for coverage cannot be found Sebastian Holtermann (2): Autogen: Backport autogen target dependency as file dependency fix Autogen: Tests: Backport tests for _autogen target dependencies -- 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] Custom script invocation from imported target
Hi, You are correct that as it stands it is challenging to add custom linking / compilation steps in CMake for moc The challenge with these approaches is that you 1. The unfortunate truth is that a cmake configure time script lacks the required information. Numerous things such as the location of libraries or config type need to be delayed to generation or execution time. 2. Things such as CUDA separable compilation, and I believe MOC, and HSL/GSL also need to invoke the original COMPILATION and LINK steps but now with additional libraries or objects that need to be added. 3. My thinking is you really wanting better ability to add custom languages to CMake. Have you explored having SYCL as a custom language? 4. With CMake 3.9 CUDA ptx compilation is natively supported using OBJECT libraries and the CUDA_PTX_COMPILATION property On Wed, Sep 20, 2017 at 8:12 AM, Nagy-Egri Máté Ferenc via cmake-developerswrote: > Hi! > > > > I am trying to improve the developer experience of SYCL users for both those > using triSYCL and ComputeCpp alike. (TL;DR: SYCL is CUDA of OpenCL, triSYCL > being a non-conforming playground implementation built atop OpenMP, while > ComputeCpp is the first (and only) conforming GPU-accelerated > implementation.) Although they are two wildly different implementations, it > would come in handy to mix the two, having Debug builds rely on triSYCL (for > the usual breakpoint-style debugging inside kernels) and Release builds > using ComputeCpp, as well as generally allowing any implementation to be > detected and used (much like find_package(MPI) can find MPI-CH, MS-MPI as > well as OpenMPI). > > > > My problem is that even if I have the nicest imported target set up in a > FindModule.cmake script with components pointing to the various > implementations (my initial take on the problem), there is no way for me to > call the ComputeCpp compiler just by linking to an imported library target. > This was the reason CUDA up until CMake 3.9 used add_cuda_executable() > function and is the same reason why ComputeCpp uses the add_sycl_to_target() > function. > > > > If I would like to raise the bar to the level of CUDA in terms of UX, I’d > need to patch CMake to being SYCL-aware. It would be much simpler however if > imported targets had the ability to invoke user-defined scripts (defined in > the FindModule.cmake script) that is invoked with the supplied parameters. > Something like: > > > > # FindLibrary.cmake > > set(important „something important”) > > > > function(add_stuff_to_target TARGET target > > IMPORTANT_VAR var) > > … > > endfunction(add_stuff_to_target) > > > > add_library(Vendor::Library INTERFACE IMPORTED) > > > > # NOTE: TARGET is always added as a param to SCRIPT when linked to. > > # NOTE 2: SCRIPT is only valid for IMPORTED libraries. > > set_target_properties(Vendor::Library PROPERTIES SCRIPT add_stuff_to_target > > SCRIPT_PARAMS IMPORTANT_VAR > ${important}) > > > > # CMakeLists.txt > > find_package(Vendor REQUIRED COMPONENTS Library) > > > > add_executable(MyProg main.cpp) > > > > target_link_libraries(MyProg PRIVATE Vendor::Library) > > > > This (or some similar way) libraries need not necessarily have to patch > CMake in order to implement features such as: > > Qt MOC-ing files > CUDA ptx compilation > HLSL/GLSL compilation (this could be an object library that is linked to a > CUSTOM_SCRIPT enhanced imported library > XAML compiler invocation > SYCL force include file generation > I’m sure there are many more similar use cases > > > > The function would always receive the target name, from where just about > everything can be queried, things originating from the FindModule.cmake > script (counterparts to vars like CMAKE_AUTOMOC) could be passed in as well. > > > > > > > > To sum it up: do you see value in lowering the bar to this level in adding > significant facilities to CMake independently of CMake itself? This way, > these facilities would be much more agile if updates to them need not wait > for a new CMake version. > > > > Cheers, > > Máté > > > -- > > 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
Re: [cmake-developers] Adding compile and build type tests to CMake/CTest
On 9/18/2017 8:16 AM, Brad King wrote: On 09/15/2017 09:22 AM, Edward Diener wrote: A gui environment like Visual Studio does provide functionality to just compile one or more source files, and it also provides functionality to just build an executable from one or more source files without actually running that executable. Yes. We just need it to be generated separately from the main build system so that "Build Solution" or our ALL_BUILD.vcxproj don't try to build the tests. Some work will be needed on the CMake side to do this in a built-in way. Do you happen to know if/how it is possible to take a .vcxproj with multiple source files (ClCompile entries) and use MSBuild to compile just one of the sources from the command-line? The IDE must do it somehow with the right-click "Compile" option. Similarly in Xcode? I do not know much about MSBuild since I have normally used the IDE. I would just like to see a built-in equivalent to testing under CMake which involves only a successful compilation or not, equivalent to Boost Build's 'compile/compile-fail' rule and a built-in equivalent to testing which involves only a successful build or not of a non-build target equivalent to Boost Build's 'link/link-fail' rule. I think both of the latter are valid testing methodologies which do not involve an actual run-time test. Yes, having a built-in solution would be nice. Currently these can only be achieved indirectly by writing tests that configure projects that are not configured by CMake as part of the main project. BTW, where is the corresponding discussion of this problem on the Boost side taking place? When the original announcement from the Boost Steering Committee was made a few months back that Boost would be moving to CMake there were numerous discussions about converting jam files to CMake and how this can be done, largely on the Boost developers mailing list. I brought up issues about how to duplicate Boost Build testing under CMake. Since then there has been little further discussion about this or indication by the Boost Steering Committee how this was to be done, on the developers mailing list. One implementation popularly considered is on Github as https://github.com/boost-cmake/bcm, but that implementation of a pure compile test is a kludge IMO, which led to this discussion here. 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] Custom script invocation from imported target
Hi! I am trying to improve the developer experience of SYCL users for both those using triSYCL and ComputeCpp alike. (TL;DR: SYCL is CUDA of OpenCL, triSYCL being a non-conforming playground implementation built atop OpenMP, while ComputeCpp is the first (and only) conforming GPU-accelerated implementation.) Although they are two wildly different implementations, it would come in handy to mix the two, having Debug builds rely on triSYCL (for the usual breakpoint-style debugging inside kernels) and Release builds using ComputeCpp, as well as generally allowing any implementation to be detected and used (much like find_package(MPI) can find MPI-CH, MS-MPI as well as OpenMPI). My problem is that even if I have the nicest imported target set up in a FindModule.cmake script with components pointing to the various implementations (my initial take on the problem), there is no way for me to call the ComputeCpp compiler just by linking to an imported library target. This was the reason CUDA up until CMake 3.9 used add_cuda_executable() function and is the same reason why ComputeCpp uses the add_sycl_to_target() function. If I would like to raise the bar to the level of CUDA in terms of UX, I’d need to patch CMake to being SYCL-aware. It would be much simpler however if imported targets had the ability to invoke user-defined scripts (defined in the FindModule.cmake script) that is invoked with the supplied parameters. Something like: # FindLibrary.cmake set(important „something important”) function(add_stuff_to_target TARGET target IMPORTANT_VAR var) … endfunction(add_stuff_to_target) add_library(Vendor::Library INTERFACE IMPORTED) # NOTE: TARGET is always added as a param to SCRIPT when linked to. # NOTE 2: SCRIPT is only valid for IMPORTED libraries. set_target_properties(Vendor::Library PROPERTIES SCRIPT add_stuff_to_target SCRIPT_PARAMS IMPORTANT_VAR ${important}) # CMakeLists.txt find_package(Vendor REQUIRED COMPONENTS Library) add_executable(MyProg main.cpp) target_link_libraries(MyProg PRIVATE Vendor::Library) This (or some similar way) libraries need not necessarily have to patch CMake in order to implement features such as: - Qt MOC-ing files - CUDA ptx compilation - HLSL/GLSL compilation (this could be an object library that is linked to a CUSTOM_SCRIPT enhanced imported library - XAML compiler invocation - SYCL force include file generation - I’m sure there are many more similar use cases The function would always receive the target name, from where just about everything can be queried, things originating from the FindModule.cmake script (counterparts to vars like CMAKE_AUTOMOC) could be passed in as well. To sum it up: do you see value in lowering the bar to this level in adding significant facilities to CMake independently of CMake itself? This way, these facilities would be much more agile if updates to them need not wait for a new CMake version. Cheers, Máté -- 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] Proposal: Support more protoc options in FindProtobuf
On 09/19/2017 07:50 PM, Peter Mitrano wrote: > Does this sound reasonable? Would this be something I could contribute? Yes, see: https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst for instructions. 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] GCC x cmake
On Tue, Sep 19, 2017 at 11:34 AM, Ivam Prettiwrote: > I would like to know what are the advantages or difference when compared >> to GCC compiler. >> >> > I understand from the topic you mean compared to cmake; but the two are > two different things > gcc is a compiler > cmake is a build system that uses compilers > it'd be more meaningful to say make v cmake... > > so there is no comparison... definatly an apples and steak comparison (or > orange would at least be fruit) > I think it's even more accurate to say CMake is not a buildsystem either, but a *generator* of buildsystems. How it works: CMake generates a buildsystem (such as Makefiles, build.ninja, a Visual Studio .sln file). Then a build tool (such as make, ninja, Visual Studio, XCode) interprets that buildsystem to issue compilation commands. These commands are executed by a compiler (such as gcc, clang, cl). I fully agree with comparing GCC to CMake being an apples to steaks comparison (and I'm stealing that phrase for future use) :-) Petr -- 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