[cmake-developers] CMake version to build CMake
Hi, Currently CMake requires a minimum of CMake 2.8.4 to build. I was reviewing the cmake-server work from Tobias starting with the libuv integration, and I think CMake might benefit from using ALIAS targets in its own build. ALIAS targets were introduced in CMake 2.8.12 (released August 2013). What do you think of updating the requirement to that or higher? Thanks, Steve. -- 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] Developer tasks - Refactoring
Daniel Pfeifer wrote: > On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly > wrote: >> 3) Compute cmGeneratorTarget state non-lazily in its constructor. >> * Historically target state for generators was computed lazily because it >> might need to be cleared and re-computed. That is no-longer true. > > SourceFilesMap is cleared in a call to AddSource. It is then > recomputed the next time GetSourceFiles is called. Hmm, maybe there is a way to reduce the amount of times it is cleared, once the computation sequence is better defined by being extracted to cmComputeTarget. cmGeneratorTarget::AddSource is currently called from several generate-time locations, some of which could become compute-time locations. The uses in * cmQtAutoGeneratorInitializer::InitializeAutogenSources * cmGlobalVisualStudio8Generator::AddCheckTarget * cmLocalVisualStudio7Generator::CreateVCProjBuildRule * cmGlobalXCodeGenerator seem that way to me, because the file names don't depend on anything from the cmGeneratorTarget which is only known at build time. Unless I'm missing something, they could be added to the list of files for the cmComputeTarget at compute time before the SourceFilesMap is populated at generate time. The tricky case is when AddSource is called with something computed from the result of cmGeneratorTarget::GetSources. The only case of that seems to be SetupSourceFiles in cmQtAutoGeneratorInitializer. That calls AddSource in a loop. If cmComputeTarget gains an AddSource and doesn't have a SourceFilesMap, then that would be the only use of cmGeneratorTarget::AddSource. That could then be replaced with a new AddSources or AddSourcesForRCC, or something better might be possible. This is just a brain-dump which I haven't investigated. You might find some facts which make the source addition refactoring to compute time to be impossible. Then maybe the entries of the ComputedTargets map might not have to be recomputed lazily. > Please review: > https://github.com/purpleKarrot/CMake/commits/computed-target Cool, thanks for working on this! I am a bit confused by the first commit in the branch. It removes some c++ template code while adding cmComputeTarget. I think that's because you make the working class inherit from cmComputeTarget, and you do that just to re- use the data members, and then later in the branch, to re-use the cmComputeTarget itself. Is it possible to split what is happening in that commit? Is it possible to remove the template code first without introducing cmComputeTarget? Even if doing so would mean introducing a struct with the same data members early in the branch and perhaps removing that struct later, I think it might make the commit more clear. Currently I don't understand it. I also generally recommend to put the most obvious/cleanup commits at the start of the branch (or even in a separate minor-cleanups branch). The 'don't clear container in destructor' commit and the 'use erase-unique instead of reinitialization' commit and the 'factor out common part of AddSources commands' all seem to fit that description. I was able to rebase them at least, but I didn't try building the result. Getting those kinds of commits out of the way first makes the rest of the branch smaller and focused on extending the code in only one specific way. Thanks, Steve. -- 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] Developer tasks - Refactoring
On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly wrote: > 3) Compute cmGeneratorTarget state non-lazily in its constructor. > * Historically target state for generators was computed lazily because it > might need to be cleared and re-computed. That is no-longer true. SourceFilesMap is cleared in a call to AddSource. It is then recomputed the next time GetSourceFiles is called. > * For example, the LinkInformation is populated lazily in > cmGeneratorTarget::GetLinkInformation. > * Instead the LinkInformation could be populated in the cmGeneratorTarget > constructor for all known configurations. That is what generators will > request during generate-time anyway. > * Doing this will make it possible to split a cmComputedTarget out of > cmGeneratorTarget. I started splitting out a cmComputedTarget. It is initialized in its constructor for one single configuration. The entries of the ComputedTargets map are computed and recomputed lazily because of the reason mentioned above. Please review: https://github.com/purpleKarrot/CMake/commits/computed-target -- 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] [ANNOUNCE] CMake 3.6.2 available for download
We are pleased to announce that CMake 3.6.2 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.6.2 since 3.6.1: Ben Boeckel (3): Intel-C: declare support for gnu11 Intel-C: support gnu89 and gnu99 extension flags Intel-C: standard flags are also supported in 12.0 Brad King (11): Add script to update curl from upstream curl: Update script to get curl 7.50.1 curl: Remove CMake-specific README VS: Fix VS 2015 .vcxproj debug setting for Windows7.1SDK toolset GetPrerequisites: Fix regression in gp_resolved_file_type Fortran: Fix .mod file comparison for Intel 16 format VS: Fix VS 2015 .vcxproj debug setting for v80 toolset FindHDF5: Fix regression in providing HDF5_IS_PARALLEL FindHDF5: Fix regression in finding hdf5hl_fortran curl: Backport certificate reuse fix from 7.50.2 CMake 3.6.2 Chuck Atkins (2): FindHDF5: Make sure compile definition vars keep the -D flag CrayLinuxEnvironment: Add alternative methods to get version info Curl Upstream (2): curl 2015-08-11 (1a7f66a3) curl 2016-08-03 (f2cb3a01) Fujii Hironori (1): VS: Fix out-of-bounds write on empty Nsight Tegra version Konstantin Sinitsyn (1): FindProtobuf: Restore support for PROTOBUF_IMPORT_DIRS -- 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] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/"
Thank you, it is working as expected. On Wed, Sep 7, 2016 at 8:26 AM, Brad King wrote: > On 09/06/2016 04:31 PM, Ben Keller wrote: >>> Please post the patch. >> Thank you > > Thanks, applied with minor tweaks: > > install: Fix computed import prefix in export files when it is "/" > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290e4ce8 > > Please try out that version. > > -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] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/"
On 09/06/2016 04:31 PM, Ben Keller wrote: >> Please post the patch. > Thank you Thanks, applied with minor tweaks: install: Fix computed import prefix in export files when it is "/" https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290e4ce8 Please try out that version. -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
