summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'backport-3.17-automoc_timestamp_deps' into release-3.17Brad King2020-08-058-3/+104
|\ | | | | | | Merge-request: !5085
| * AutoGen: Add test to check for correct AutoMoc dependenciesAlexandru Croitor2020-08-036-0/+56
| | | | | | | | | | | | When using Qt 5.15.0 or above together with Ninja, check that touching a source file of a dependency does not needlessly re-run AUTOMOC for the dependee target.
| * AutoGen: Fix over-specified direct dependencies of custom commandAlexandru Croitor2020-08-032-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AutoMoc timestamp creating custom command explicitly depended on all dependencies of the origin target (associated to the AutoGen target). When an origin target depended on a shared library 'libfoo.so', if it was re-linked, the AutoMoc custom command would touch its output timestamp file, and thus cause needless rebuilding of sources, despite the shared library not having any influence on the AutoMoc generated files. Introduce a new '<target>_autogen_timestamp_deps' utility target, which will serve as an 'order-only' dependency for the custom command. This will prevent needless rebuilding, because touching 'libfoo.so' will not cause the custom command to be re-executed. The new AutoMoc dependency tree looks like: '_autogen_timestamp_deps (serves as order-only dep)' <- '<target_autogen>/timestamp' file ( + moc deps file) <- '<target>_autogen' target. Fixes: #21020
* | Merge branch 'ninja-multi-rsp-remove-path' into release-3.17Brad King2020-08-031-10/+2
|\ \ | |/ |/| | | Merge-request: !5094
| * Ninja: Restore shorter path to response filesKyle Edwards2020-08-031-10/+2
|/ | | | | | | | | | | | In commit 99ed39b011 (Ninja Multi-Config: Make link response files per-config, 2020-07-15, v3.17.4~3^2), we added the target directory to the response file under the mistaken assumption that two different targets with the same name could be in different directories. However, this causes the path to the response file to be too long to fit on a command line. Take the path back out, while leaving in the per-config split. Fixes: #21050
* CMake 3.17.4v3.17.4Brad King2020-07-301-1/+1
|
* Merge branch 'bootstrap-intel' into release-3.17Brad King2020-07-241-1/+1
|\ | | | | | | Merge-request: !5057
| * bootstrap: Fix support for Intel compiler with modern GNU system compilerBrad King2020-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On systems with older GNU system compilers, the Intel C++ compiler does not define `__cplusplus` to any version newer than C++11. This prevented `bootstrap` from detecting that a given C++ standard flag has enabled C++17 mode in the compiler. In commit 033a4b12a5 (bootstrap: Extend C++17 check for our cast functions, 2019-12-14, v3.17.0-rc1~291^2) we added a preprocessor condition to attempt to detect C++17 mode in the Intel compiler on such systems by looking for `__cpp_if_constexpr`. However, on systems with a modern GNU system compiler, that definition is available even in C++11 mode. Switch to using `__cpp_deduction_guides` to detect C++17 mode for the Intel C++ compiler. That seems to be defined exclusively in C++17 mode regardless of the version of the system compiler. Fixes: #21013
* | Merge branch 'backport-3.17-graphviz-restore-per-target' into release-3.17Brad King2020-07-215-7/+201
|\ \ | | | | | | | | | Merge-request: !5039
| * | Tests: Cover Graphviz support for per-target dependency graph optionsStephan Rohmen2020-07-213-0/+56
| | | | | | | | | | | | Issue: #20928
| * | Graphviz: Restore support for per-target dependency graph optionsStephan Rohmen2020-07-212-7/+145
| |/ | | | | | | | | | | | | | | | | | | | | | | | | The behaviors controlled by options `GRAPHVIZ_GENERATE_PER_TARGET` and `GRAPHVIZ_GENERATE_DEPENDERS` were broken by commit 553658393c (Graphviz: added test suite, fixes, enhancements, 2019-10-08, v3.17.0-rc1~615^2). It had not been covered in the test suite previously, and those changes left out checks for these features from the `default_options` case. Implement the previously-existing behavior in the new graphviz generation engine added by the above-mentioned commit. Fixes: #20928
* | Merge branch 'ninja-multi-rsp' into release-3.17Brad King2020-07-161-4/+14
|\ \ | | | | | | | | | Merge-request: !5020
| * | Ninja Multi-Config: Make link response files per-configKyle Edwards2020-07-161-4/+14
| |/ | | | | | | Fixes: #20961
* | Merge branch 'FindOpenSSL-3.0' into release-3.17Brad King2020-06-081-2/+4
|\ \ | | | | | | | | | Merge-request: !4860
| * | FindOpenSSL: Fix OpenSSL 3.0.0 version extractionBilly Brumley2020-06-081-2/+4
| |/ | | | | | | | | | | | | | | Fix the regex syntax added by commit 61d746e592 (FindOpenSSL: Detect OpenSSL 3.0.0, 2020-05-27, v3.17.3~1^2). Add missing escapes. Test with `openssl-3.0.0-alpha3`. While at it, also unset a temporary variable after use.
* | Merge topic 'pch-no-Fortran' into release-3.17Brad King2020-06-032-11/+15
|\ \ | | | | | | | | | | | | | | | | | | 10c88c4337 PCH: Do not enable GNU or Intel PCH settings for Fortran Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4843
| * | PCH: Do not enable GNU or Intel PCH settings for FortranBrad King2020-06-022-11/+15
| |/ | | | | | | | | | | | | | | | | The PCH settings are shared by C and CXX languages but do not make sense for Fortran. In particular, `CMAKE_PCH_EXTENSION` should not be set because it can overwrite the value set for C/C++ languages, which may have a different compiler vendor than the Fortran compiler. Fixes: #20752
* | Merge topic 'vs-sln-version-16' into release-3.17Brad King2020-06-031-1/+1
|\ \ | | | | | | | | | | | | | | | | | | b69010b719 VS: Fix .sln support for VS Version Selector with VS 2019 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4844
| * | VS: Fix .sln support for VS Version Selector with VS 2019Brad King2020-06-021-1/+1
| |/ | | | | | | | | | | VS 2019 changed the naming pattern used by 2015 and 2017. Fixes: #20783
* | Merge branch 'release-3.16' into release-3.17Brad King2020-06-010-0/+0
|\ \
| * | CMake 3.16.8v3.16.8Brad King2020-06-011-1/+1
| | |
| * | Merge branch 'backport-3.16-pch-fix-bad-ClearSourcesCache' into release-3.16Brad King2020-05-293-5/+22
| |\ \ | | | | | | | | | | | | Merge-request: !4815
* | \ \ Merge topic 'pch-fix-bad-ClearSourcesCache' into release-3.17Brad King2020-06-013-5/+22
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 902858367f Merge branch 'backport-3.16-pch-fix-bad-ClearSourcesCache' fa7b041eca PCH: Fix logic error that incorrectly clears sources during VS generation Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4815
| * \ \ \ Merge branch 'backport-3.16-pch-fix-bad-ClearSourcesCache'Brad King2020-05-293-5/+22
| |\ \ \ \ | | | |/ / | | |/| / | | |_|/ | |/| |
| | * | PCH: Fix logic error that incorrectly clears sources during VS generationBrad King2020-05-293-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 729d997f10 (Precompile Headers: Add REUSE_FROM signature, 2019-08-30, v3.16.0-rc1~101^2), `GetPchFileObject` handles the case that it is called first for another target's `REUSE_FROM` by calling `AddSource` to make sure `GetObjectName` can produce the correct object name. However, `AddSource` causes `ClearSourcesCache` to be called, which since commit a9f4f58f0c (cmGeneratorTarget: Clear AllConfigSources in ClearSourcesCache, 2020-05-15, v3.16.7~2^2) now correctly erases the `AllConfigSources` structure. This is okay during `AddPchDependencies`, but there is another code path in which it is problematic. When the Visual Studio generator's `WriteAllSources` method is looping over the sources, the `cmake_pch.cxx` source is encountered first. This causes `OutputSourceSpecificFlags` to call `GetPchCreateCompileOptions`, which calls `GetPchFile`, which under MSVC with `CMAKE_LINK_PCH` calls `GetPchFileObject`. That leads to `ClearSourcesCache` erasing the structure over which `WriteAllSources` is iterating! This bug is caught by our `RunCMake.PrecompileHeaders` test when run with the VS generator as of the commit that exposed it by fixing `ClearSourcesCache`. However, that change was backported to the CMake 3.16 series after testing only with later versions versions that contain commit a55df20499 (Multi-Ninja: Add precompile headers support, 2020-01-10, v3.17.0-rc1~136^2). By adding proper multi-config support for PCH, that commit taught `cmLocalGenerator::AddPchDependencies` to call `GetPchFile` with the real set of configurations instead of just the empty string. This allows the `GetPchFile` cache of PCH sources to be populated up front so that the later calls to it in the `WriteAllSources` loop as described above do not actually call `GetPchFileObject` or `ClearSourcesCache`. That hid the problem. Fix this by re-ordering calls to `AddPchDependencies` to handle `REUSE_FROM` targets only after the targets whose PCH they re-use. Remove the now-unnecessary call to `AddSource` from `GetPchFileObject` so that `ClearSourcesCache` is never called during `WriteAllSources`. Update the PchReuseFrom test case to cover an ordering of targets that causes generators to encounter a `REUSE_FROM` target before the target whose PCH it re-uses. Fixes: #20770
* | | | Merge topic 'ninja-multi-export-all-symbols' into release-3.17Brad King2020-06-012-1/+4
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6fc4bfa11c Ninja Multi-Config: Fix bug in CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Alex Reinking <alex_reinking@berkeley.edu> Merge-request: !4825
| * | | | Ninja Multi-Config: Fix bug in CMAKE_WINDOWS_EXPORT_ALL_SYMBOLSKyle Edwards2020-05-292-1/+4
|/ / / / | | | | | | | | | | | | Fixes: #20775
* | | | Merge topic 'FindSubversion-xcode-removed' into release-3.17Brad King2020-05-291-2/+11
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | 2c0db404d1 FindSubversion: Do not accept macOS stub without Xcode implementation Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4813
| * | | FindSubversion: Do not accept macOS stub without Xcode implementationBrad King2020-05-281-2/+11
|/ / / | | | | | | | | | | | | Xcode no longer provides a `svn` implementation, but the `/usr/bin/svn` stub may still exist.
* | | CMake 3.17.3v3.17.3Brad King2020-05-281-1/+1
| | |
* | | Merge topic 'openssl-3.0.0' into release-3.17Brad King2020-05-281-0/+9
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 61d746e592 FindOpenSSL: Detect OpenSSL 3.0.0 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4805
| * | | FindOpenSSL: Detect OpenSSL 3.0.0Vitezslav Cizek2020-05-271-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OpenSSL versioning is changing with the upcoming 3.0.0 release. https://www.openssl.org/blog/blog/2018/11/28/version/ Since 3.0.0, the patch letters are being dropped. The new format is: MAJOR.MINOR.PATCH The OPENSSL_VERSION variable can now be directly derived from the new OPENSSL_VERSION_STR macro. https://www.openssl.org/docs/manmaster/man3/OPENSSL_VERSION_NUMBER.html
* | | | Merge topic 'fix-cpack-deb-generating-empty-paragraph' into release-3.17Brad King2020-05-283-12/+12
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6ba842163c CPack-deb: don't add a line with a dot to pkg desc Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4806
| * | | | CPack-deb: don't add a line with a dot to pkg descJonathan Verner2020-05-273-12/+12
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, if the package description ends with a newline (typically if it is read from a file) cpack -deb adds a single line with a dot at the end which leads to a violation of the `extended-description-contains-empty-paragraph` debian policy. This commit fixes the above behaviour. Fixes: #20763
* | | | Merge topic 'ctest-repeat-notrun' into release-3.17Brad King2020-05-276-6/+54
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bbb62dcc72 CTest: Make sure NOT_RUN tests show up in the failed test log c503251997 Tests: Add coverage of ctest_test RETURN_VALUE and REPEAT Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4801
| * | | | CTest: Make sure NOT_RUN tests show up in the failed test logRobert Maynard2020-05-276-1/+33
| | | | | | | | | | | | | | | | | | | | Issue: #20543
| * | | | Tests: Add coverage of ctest_test RETURN_VALUE and REPEATRobert Maynard2020-05-271-5/+21
| |/ / /
* | | | Merge branch 'release-3.16' into release-3.17Brad King2020-05-270-0/+0
|\ \ \ \ | | |_|/ | |/| |
| * | | CMake 3.16.7v3.16.7Brad King2020-05-271-1/+1
| | | |
| * | | Merge branch 'vs-sln-version' into release-3.16Brad King2020-05-191-0/+1
| |\ \ \ | | | | | | | | | | | | | | | Merge-request: !4765
| * \ \ \ Merge branch 'fix-ClearSourcesCache' into release-3.16Brad King2020-05-151-0/+1
| |\ \ \ \ | | | |_|/ | | |/| | | | | | | Merge-request: !4751
| * | | | Merge branch 'backport-3.16-FindPkgConfig-isystem' into release-3.16Brad King2020-05-151-0/+6
| |\ \ \ \ | | | | | | | | | | | | | | | | | | Merge-request: !4752
* | \ \ \ \ Merge topic 'doc-updates' into release-3.17Brad King2020-05-252-7/+9
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | b3e4fb5144 Help: clarify add_definitions() and add_compile_definitions() behavior Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4786
| * | | | | | Help: clarify add_definitions() and add_compile_definitions() behaviorMarc Chevrier2020-05-242-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: #20736
* | | | | | | Merge topic 'ninja-multi-install' into release-3.17Brad King2020-05-256-6/+117
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dddb4f02f7 Ninja Multi-Config: Make "install" targets depend on default configs Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4778
| * | | | | | Ninja Multi-Config: Make "install" targets depend on default configsKyle Edwards2020-05-226-6/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And add an "install:all" target. Fixes: #20713
* | | | | | | Merge topic 'cuda-default-runtime' into release-3.17Brad King2020-05-2212-7/+65
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e55b21e24e CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchain 1086e930dc CUDA: Propagate CMAKE_CUDA_RUNTIME_LIBRARY state to try_compile a4ea293153 Help: Correct CMAKE_CUDA_RUNTIME_LIBRARY applicability Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4762
| * | | | | | CUDA: Compute CMAKE_CUDA_RUNTIME_LIBRARY default from toolchainRobert Maynard2020-05-2110-6/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 0d0145138f (CUDA: Add abstraction for cuda runtime selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library selection flags by default. To maintain backwards compatibility the default CUDA runtime library needs to be computed based on what libraries are found on the initial compiler invocation. For example a toolchain could establish initial flags that have all CUDA compilations using the runtime version, and if we don't detect this we will try to link to both the static and shared runtime. Co-Author: Brad King <brad.king@kitware.com> Fixes: #20708
| * | | | | | CUDA: Propagate CMAKE_CUDA_RUNTIME_LIBRARY state to try_compileRobert Maynard2020-05-202-0/+4
| | | | | | |
| * | | | | | Help: Correct CMAKE_CUDA_RUNTIME_LIBRARY applicabilityRobert Maynard2020-05-201-1/+1
| | | | | | |