[cmake-developers] Integrate tools with cmake
Hello, I am currently developing some projects which involves a build system and some tools. I would like to know what are the possibilities when it comes to integrate other tools in the cmake build system? How can that be done and what are the obstacles for achieving that? Thanks and regards, Adrian 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-developers
Re: [cmake-developers] [Patch 5/5] Improved WIX support
On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Using the patchfile support I managed to implement the service installation issue I had, so the unnecessary features from the last patch are removed now. I tested all patches separately and hope they work now. looking forward for feedback, best regrads, Michael Patch 5 seems to implement patching of FeatureRef rather than the original Feature elements. I am not sure if this is what you intended but this could be error prone given that there could in theory be any number (0-n) FeatureRef elements for any corresponding Feature element. 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] Integrate tools with cmake
Hi there,
Depends on what you mean by "tools". If you mean running some sort of
static analysis over your code, there's a few ways to do it. I prefer
to use add_custom_command which generates a new makefile based on some
output stampfile. You can make the stampfile depend on the input file
that you're analysing and add the stampfile as a source-level
dependency to your built library or binary. This way, the tool will be
re-run every time you modify the file.
For instance:
add_custom_command (OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${SOURCE_NAME}.stamp
COMMAND my-tool ${SOURCE_NAME}
COMMAND ${CMAKE_COMMAND}
-E touch ${CMAKE_CURRENT_BINARY_DIR}/${SOURCE_NAME}.stamp
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/${SOURCE_NAME}
COMMENT "Running my-tool
on ${SOURCE_NAME}")
[self-promotion]: I was doing this for quite a few tools, so I wrote a
module to quickly define functions that allow you to run various tools
over source files:
https://github.com/polysquare/tooling-cmake-util/blob/master/PolysquareToolingUtil.cmake
It has some dependencies which you can either install using conan or
just add them as git submodules and set CMAKE_MODULE_PATH
appropriately.
You can contact me on this email address if you need any help.
Thanks,
Sam.
On Fri, Aug 12, 2016 at 3:17 PM, Costean Adrian via cmake-developers
wrote:
> Hello,
> I am currently developing some projects which involves a build system and
> some tools. I would like to know what are the possibilities when it comes to
> integrate other tools in the cmake build system? How can that be done and
> what are the obstacles for achieving that?
> Thanks and regards,
> Adrian 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-developers
--
Sam Spilsbury
--
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] toolset Clang 3.7 with Microsoft CodeGen (v140_clang_3_7) debug is broken
Le 2016-05-02 20:48, foru...@.com a écrit : Le 2016-05-02 20:41, Brad King a écrit : On 05/02/2016 02:17 PM, foru...@x.com wrote: Don't know if it's the best place to report it but I am testing nightly builds(3.5.20160429) to generate some projects for Visual Studio 2015 and the clang toolset now provided by Microsoft. Yes, this is the right place to report it, especially since this is recent development. For reference, support for this toolset was added in a topic merged here: Merge topic 'vs-clang-cl' https://cmake.org/gitweb?p=cmake.git;a=commit;h=612a8b3b based on discussion in this thread: [PATCH SET] Support of Clang/C2 compiler. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15902 I have found some changes that seems to be necessary to be able to debug, here are the changes I have found: 1) DebugInformationFormat should be set FullDebug, AdditionalOptions MUST BE removed and optimizations must be disabled ... REMOVE AdditionalOptions ... FullDebug ... Disabled false 2)GenerateDebugInformation must be set to true and ProgramDataBaseFile must be empty because clang doesn't use pdb for now ... true ... Mariusz, please take a look at this. See also this hack: VS: Fix VS 2015 .vcxproj debug setting for older toolsets https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc422d27 Basically we need to have a different flag table for each possible toolset. Also it looks like additional special handling may be needed for PDBs and perhaps other limitations of the Clang/C2 toolchain. Thanks, -Brad Just a small update about what I wrote regarding AdditionalOptions, I found that it's not necessary to remove the whole line but only the -gline-tables-only parameter. Hi, I have tested cmake 3.6.1 with the last release of the clang platform by Microsoft (v140_clang_c2) and nothing has changed. By default cmake generates wrong projects with this toolset. So could we fix it step by step: In the next release of cmake could you please remove the -gline-tables-only (and maybe all the additional arguments you provide because Microsoft don't add them when using Visual to generate projects) Then if you have time please Disable Optimizations in Debug and finally please set DebugInformationFormat for debug configurations. For now I have to manually fix all my projects everytime I regenerate them and it's not very funny. Thanks -- 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 5/5] Improved WIX support
On 08/12/2016 11:50 AM, Stuermer, Michael SP/HZA-ZSEP wrote: Patch 5 seems to implement patching of FeatureRef rather than the original Feature elements. I am not sure if this is what you intended but this could be error prone given that there could in theory be any number (0-n) FeatureRef elements for any corresponding Feature element. Nils The intention was to be able to add custom components that are added as extra .wxs source files to certain features. If there are more convenient ways to do this I will be happy to change the implementation or adapt my WIX project. But so far this seemed to be a very easy and intuitive solution: the additional component references are added in the same place where all other component references are added as well. I understand the general intention but not why you elected to patch FeatureRef elements instead of the Feature elements themselves. This would not be any more convenient but would certainly match expectations and be less ill defined. e.g. when I specify a patch for a Feature I expect that the Feature with the given ID gets patched. Arguments against patching a FeatureRef instead are: - There can be n FeatureRef elements for any Feature element in which case it would not be obvious if the patch should be applied to one (which?) or all of these - While similar FeatureRef and Feature don't take the same Child elements - You can already define your own FeatureRef elements (referencing any of the pre-existing Feature elements if wanted) without having to use the patch mechanism 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 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, August 12, 2016 9:42 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > best regrads, > > Michael > > > > Patch 5 seems to implement patching of FeatureRef rather than the original > Feature elements. > I am not sure if this is what you intended but this could be error prone given > that there could in theory be any number (0-n) FeatureRef elements for any > corresponding Feature element. > > Nils The intention was to be able to add custom components that are added as extra .wxs source files to certain features. If there are more convenient ways to do this I will be happy to change the implementation or adapt my WIX project. But so far this seemed to be a very easy and intuitive solution: the additional component references are added in the same place where all other component references are added as well. Michael -- 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] Need ideas/opinions on third party library management
> > This is what Spack and other meta builders do. I don't think CMake is the > best place to do it, for a number of reasons. I would not try to re-invent > the wheel here. > See http://github. com/llnl/spack > -- Elizabeth -- 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] Bugfix: Default behavior of CUDA_USE_STATIC_CUDA_RUNTIME
Hi Stephen, On 08/11/2016 03:37 PM, Sorley, Stephen L. wrote: > Recent changes to FindCUDA.cmake (commit 7229ae7) broke Thanks for these two fixes. I've applied them: FindCUDA: Restore default behavior of CUDA_USE_STATIC_CUDA_RUNTIME https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aab1f6e9 FindCUDA: Fix missing librt on Linux when using static cuda runtime. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1aa5c1be James, do these look good to you? 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] toolset Clang 3.7 with Microsoft CodeGen (v140_clang_3_7) debug is broken
On 08/12/2016 08:59 AM, Forumer 4umer wrote: > I have tested cmake 3.6.1 with the last release of the clang platform by > Microsoft (v140_clang_c2) and nothing has changed. No one is actively working on support for Clang toolsets currently. The experimental support in 3.6 was contributed but no one has maintained it. There is an issue covering the main problem: https://gitlab.kitware.com/cmake/cmake/issues/16153 Discussion there has links to some of the other problems. -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] toolset Clang with Microsoft CodeGen (v140_clang_c2) debug is broken
And if you need more information please look at the thread entitled "toolset Clang 3.7 with Microsoft CodeGen (v140_clang_3_7) debug is broken" a few months ago. -- 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] Android Support
That's super awesome Brad! Looking forward to try this out! -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Friday, August 12, 2016 11:13 AM To: cmake-developers@cmake.org Subject: [cmake-developers] Android Support Hi Folks, I've implemented native support for cross-compiling to Android with CMake using either an Android NDK or an Android Standalone Toolchain. I plan to include this in the CMake 3.7 release. Please see the MR here: https://gitlab.kitware.com/cmake/cmake/merge_requests/62 This enables building with simple toolchain files, or even without one: $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk Note that interface compatibility with popular third-party Android toolchain files is a non-goal of this work (though we should not break them too much). Instead I'd like to make the support feel native within CMake. For example, the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. If you're interested in this support please fetch the MR branch and try it out. The Help/manual/cmake-toolchains.7.rst manual has been updated with documentation about how to use this. -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 -- 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] Android Support
Hi Folks, I've implemented native support for cross-compiling to Android with CMake using either an Android NDK or an Android Standalone Toolchain. I plan to include this in the CMake 3.7 release. Please see the MR here: https://gitlab.kitware.com/cmake/cmake/merge_requests/62 This enables building with simple toolchain files, or even without one: $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk Note that interface compatibility with popular third-party Android toolchain files is a non-goal of this work (though we should not break them too much). Instead I'd like to make the support feel native within CMake. For example, the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. If you're interested in this support please fetch the MR branch and try it out. The Help/manual/cmake-toolchains.7.rst manual has been updated with documentation about how to use this. -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] Need ideas/opinions on third party library management
Hello, There is an internal C++ product at the company I work for which I have written a series of CMake scripts for. This project actually has dependencies on several open source libraries, such as boost, freetype, openssl, etc. Right now what we do is build each of these third party libraries *by hand*, once for every platform we support (Windows, Linux x86, Android NDK). Then we stuff the includes (headers) and libraries (static/shared) in a submodule and the primary code base's CMake scripts pull them in as interface targets. This works well and is light-weight but is a pain when upgrading or changing libraries. It's a pain because if I want to upgrade boost, I have to build it up to 6 times (once for each platform and once for each configuration). I've been thinking of a different approach for a while. I've done some toying around with the "Super Build" concept, where I have a separate CMake project that does nothing but use the ExternalProject module to build libraries in real time along with our project. So the order of operations would be as follows (for our automated build server): 1. Clone our "Third Party" repository 2. Use CMake to generate & build the "Super Build" project (this builds boost, openssl, freetype, etc for the current platform). 3. Clone the main code base's repository 4. Use CMake to generate & build, using find_package() to refer to interface targets exported by those third party libraries built in step 2 Obviously this will make builds take significantly longer, because we're constantly rebuilding the same third party libraries over and over again. However, it virtually eliminates the maintenance burden for third party libraries because they are built inherently with everything else. Note that I can't refer to pre-built libraries in our build environments because we need very specific control over the versions of our libraries as well as the toolchains that were used to build them. Also we may specifically build our libraries a certain way (such as boost). For this reason we do not rely on our external environment or external package managers to fulfill third party dependencies, like most open source projects do on Linux for example. Does this "Super Build" approach sound like a better idea? What other options are available? The downside with the "Super Build" solution is that it will become very difficult to make the transition between building third party and building our code base seamless. I can't do both in the same generate step because find_package() can't be called until the libraries are built & installed. -- 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
