summaryrefslogtreecommitdiffstats
path: root/Tests
Commit message (Collapse)AuthorAgeFilesLines
* Apple: Properly lookup XCTest for iOS and tvOSGregor Jasny2019-05-112-0/+18
| | | | Closes: #19172
* Merge branch 'out-of-dir-linking-private-deps' into release-3.14Brad King2019-04-304-0/+30
|\ | | | | | | Merge-request: !3276
| * target_link_libraries: Fix static library private deps in other dirsBrad King2019-04-304-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | In commit a1ad0a699b (target_link_libraries: Allow use with targets in other directories, 2018-09-07, v3.13.0-rc1~94^2) we accidentally broke the logic that adds `$<LINK_ONLY:...>` to private dependencies of static libraries in their `INTERFACE_LINK_LIBRARIES` in the case that the dependency is added from outside the directory creating the library. The check for a valid target name should apply to the original name specified by the caller and not the encoded cross-directory reference. Fixes: #19197
| * Merge branch 'backport-autogen-qt-version-from-dirprops' into release-3.13Brad King2019-01-306-1/+72
| |\ | | | | | | | | | Merge-request: !2883
| | * Tests: add cases for providing Qt5Core_VERSION manuallyBen Boeckel2019-01-306-1/+72
| | |
| * | Merge branch 'backport-restore-install-late-framework' into release-3.13Brad King2019-01-292-0/+7
| |\ \ | | | | | | | | | | | | Merge-request: !2878
| | * | macOS: Restore compatibility for setting FRAMEWORK after install()Brad King2019-01-292-0/+7
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `FRAMEWORK` target property affects the way the `install()` command treats the target and so should be set first. Our implementation assumed that this was always the case and led to an assertion failure. Prior to CMake 3.12 this was visible only when using an explicit `LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made it possible with a simple `LIBRARY DESTINATION`. Fully supporting out-of-order specification will require non-trivial refactoring to defer install generator creation to generate time. For now simply restore the old behavior of installing the framework to the library destination. Fixes: #18848
| * | cmake: Convert no source/build dir error to warningCraig Scott2019-01-223-3/+15
| |/ | | | | | | | | | | | | | | | | | | Temporarily restore previous behavior that allowed specifying no source or build directory to work, even though it was neither documented nor supported. This commit is expected to eventually be reverted to restore the fatal error for such cases. Relates: #18817
| * Merge branch 'cmake-option-parsing' into release-3.13Brad King2019-01-143-14/+17
| |\ | | | | | | | | | Merge-request: !2799
* | \ Merge branch 'vs-default-platform' into release-3.14Brad King2019-04-192-0/+2
|\ \ \ | | | | | | | | | | | | Merge-request: !3246
| * | | VS: Provide the default platform name to project codeBrad King2019-04-192-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio generators based on `CMAKE_GENERATOR_PLATFORM` or some default. Prior to the VS 2019 generator, the default was always `Win32`. However, for the `Visual Studio 16 2019` generator, the default is based on the host platform. Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for use by project code. This is particularly useful in toolchain files because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so `CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that will be used. Fixes: #19177
* | | | FindBoost: Fix detection with version suffixes on GentooRolf Eike Beer2019-04-162-0/+30
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | The Gentoo case added by commit 1673923c30 (FindBoost: Add support for Boost 1.67 with Python version suffixes, 2018-03-18, v3.11.0~3^2) left out the `.` version component separator and instead duplicated the RPM case. Add the missing `.` now. Fixes: #18743
* | | Merge branch 'xcode-extra-sources' into release-3.14Brad King2019-04-111-0/+7
|\ \ \ | | | | | | | | | | | | Merge-request: !3208
| * | | Xcode: Avoid mutating App Bundle targets during generationBrad King2019-04-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For `MACOSX_BUNDLE` targets we generate an `Info.plist` automatically and add it to the sources presented to Xcode. Avoid mutating the original target's list of sources to achieve this. Otherwise when we generate the same target again (e.g. in a sub-project's Xcode file) it will look different than the first time and possibly break invariants. Fixes: #19114
* | | | Fix implicit include directory extraction for adaptive relative pathsBrad King2019-04-085-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases GCC reports *relative* implicit include directories. They are computed adaptively with respect to the current working directory such that the effective implicit include directory is an unchanging absolute path. Teach our implicit include directory extraction to recognize such paths and normalize them. Fixes: #19133
* | | | Tests: Teach RunCMake.ParseImplicitIncludeInfo to match output by regexBrad King2019-04-0816-17/+17
| | | |
* | | | Tests: Clarify hand-written cases in RunCMake.ParseImplicitIncludeInfoBrad King2019-04-085-2/+2
|/ / /
* | | Merge branch 'implicit-includes' into release-3.14Brad King2019-03-2916-70/+78
|\ \ \ | | | | | | | | | | | | Merge-request: !3157
| * | | ParseImplicitIncludeInfo: Canonicalize implicit include dirsBrad King2019-03-2916-70/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implicit include directory extraction added by commit 5990ecb741 (Compute implicit include directories from compiler output, 2018-12-07, v3.14.0-rc1~108^2) leaves paths like `/usr/lib/../include` unchanged. Fix the logic to canonicalize such paths (e.g. to `/usr/include`) as we do for implicit link directories already. This is important to ensure the set of implicit directories is represented in the same form as the include directories that will be compared to them. Issue: #19095
* | | | Merge branch 'FindFontconfig-var-case' into release-3.14Brad King2019-03-271-3/+3
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !3153
| * | | | FindFontconfig: Convert module variables to camel caseBrad King2019-03-261-3/+3
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our documented standard for find module variable names is to match the case of the find module package name. This was overlooked when the module was added by commit 84e7920b3a (FindFontconfig: Add module to find Fontconfig, 2018-09-27, v3.14.0-rc1~523^2). The module was released with the upper case names in CMake 3.14.0, so fix it to have camel case names in 3.14.1. This is incompatible but anyone using a given release series should be using the latest patch on it and we've made breaking fixups on newly released features like this before. Reported-by: Christophe Giboudeaux <christophe@krop.fr> Fixes: #19094
* | | | Restore support for include_directories() in toolchain filesBrad King2019-03-255-0/+17
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Any `include_directories()` calls in toolchain files are used during our ABI detection step even though it does not include any system headers. Since commit 5990ecb741 (Compute implicit include directories from compiler output, 2018-12-07, v3.14.0-rc1~108^2), that check is also used to detect implicit include directories. Any `include_directories()` in a toolchain file are detected as implicit and later excluded from explicit specification on compiler command lines, thus breaking the purpose of the calls in the first place. Fix the implicit include directory detection step to avoid using paths from `include_directories()` calls in the toolchain file. Fixes: #19079
* | | Merge branch 'install-no-imported-global' into release-3.14Brad King2019-03-074-0/+9
|\ \ \ | | | | | | | | | | | | Merge-request: !3071
| * | | install: Do not crash on imported global targetBrad King2019-03-074-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit e89ad0f94e (install: Allow installing targets created in another directory, 2018-06-18, v3.13.0-rc1~407^2) the `install(TARGETS)` command may find a global-scoped target outside the calling directory. Ignore an `IMPORTED GLOBAL` target if it is found in this way. Imported targets cannot be installed, and trying to do so violates internal invariants. Fixes: #19022
* | | | Merge branch 'ios-variable' into release-3.14Brad King2019-03-051-0/+4
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !3051
| * | | | iOS: Add IOS variableRuslan Baratov2019-03-051-0/+4
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | Since commit 11da882a12 (Apple: Introduce separate system name for iOS, tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) we support setting `CMAKE_SYSTEM_NAME` to `iOS`. Existing iOS toolchain files already set `IOS` as a short-hand variable, so do the same here.
* | | | Merge branch 'FindPython-NumPy-fix-include-dir' into release-3.14Brad King2019-03-041-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !3053
| * | | | FindPython: Fix NumPy component include directoryMarc Chevrier2019-03-041-1/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | Update the component added by commit 513e77550d (FindPython: Introduce NumPy component, 2018-12-12, v3.14.0-rc1~95^2). The `numpy/` sub-directory should not be part of the include directory. It should be part of the `#include` line.
* | | | VS: Fix Fortran target type selection with RC sourcesBrad King2019-03-012-1/+7
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel Fortran `.vfproj` files do support both Fortran and the Windows Resource compiler (`.rc)` files. Prior to CMake 3.9 we did not support that, but commit 2c9f35789d (VS: Decide project type by linker lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) accidentally enabled it. It was then broken by commit d3d2c3cd49 (VS: Fix Fortran target type selection when linking C++ targets, 2019-02-04, v3.14.0-rc1~13^2). Restore support for Fortran+RC in VS projects and add a test case. Fixes: #19002
* | | Merge branch 'cmake_role-vs-fix' into release-3.14Brad King2019-02-272-0/+7
|\ \ \ | | | | | | | | | | | | Merge-request: !3028
| * | | CMAKE_ROLE: Fix value in --build for Visual Studio generatorsKyle Edwards2019-02-262-0/+7
| | | | | | | | | | | | | | | | Fixes: #18990
* | | | Merge branch 'FindOctave-remove' into release-3.14Brad King2019-02-276-83/+0
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !3027
| * | | | FindOctave: Remove module pending further workBrad King2019-02-266-83/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `FindOctave` module added by commit 170bcb6fdc (FindOctave: Add module to find GNU octave, 2018-11-17, v3.14.0-rc1~283^2) has a few problems in its implementation that need to be worked out before the module can be included in a CMake release. These were missed during review. Remove the module for now. It can be restored later with a fresh review. Issue: #18991
* | | | | Merge branch 'restore-min-cmake-3.1' into release-3.14Brad King2019-02-271-3/+3
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | Merge-request: !3021
| * | | | Tests: Restore support for CMake 3.1 through 3.6 with MSVCBrad King2019-02-261-3/+3
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in commit a5dd159990 (Tests: Fix RunCMake.try_compile CxxStandard case on MSVC, 2017-09-22, v3.10.0-rc1~63^2) introduced use of `if()` conditions not supported until CMake 3.7, so while it was intended to restore support for CMake versions prior to 3.9, it actually only did so for 3.7 and 3.8. Backport the logic to work with CMake 3.1. Fixes: #18987
* | | | EXCLUDE_FROM_ALL: Don't warn if installing target excluded from allCraig Scott2019-02-211-1/+0
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | The original warning pre-dates support for install components. There are now legitimate scenarios where an install(TARGETS) command may list a target that is excluded from all, e.g. hierarchical projects that will never install the component such a target belongs to. Fixes: #18938
* | | Merge branch 'try_compile-expand-compile-defs' into release-3.14Brad King2019-02-152-0/+39
|\ \ \ | | | | | | | | | | | | Merge-request: !2965
| * | | try_compile: Restore expansion of ;-list in COMPILE_DEFINITIONSBrad King2019-02-152-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The quoting added by commit 8c5221fb1f (try_compile: Preserve special characters in COMPILE_DEFINITIONS, 2019-01-21, v3.14.0-rc1~108^2~3) broke the case that the `COMPILE_DEFINITIONS` value contains a `;`. Without the quoting the `;` would be generated literally in an unquoted argument in the test `CMakeLists.txt` file and would then be expanded. With quoting the `;` is preserved, which is not the old behavior. Fix this by expanding the `;`-list ahead of time. Add test cases for behavior with both `#` and `;`. This was noticed with the PGI compiler where we set `CMAKE_CXX*_STANDARD_COMPILE_OPTION` to values like `--c++17;-A`. The symptom had also been observed while preparing commit ef8f237686 (ParseImplicitIncludeInfo: add SunPro Fortran and PGI compiler, Cray fix, 2019-01-29, v3.14.0-rc1~26^2~2) but was not recognized at the time as a regression. Revert the workaround added by that commit. Fixes: #18919
* | | | Merge branch 'genex-GENEX_EVAL-fix-recursion' into release-3.14Brad King2019-02-132-4/+5
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !2954
| * | | | genex: Fix erroneous handling of recursion for $<GENEX_EVAL:>Marc Chevrier2019-02-132-4/+5
| |/ / / | | | | | | | | | | | | Fixes: #18894
* | | | Merge branch 'FindOctave-interp-target' into release-3.14Brad King2019-02-112-0/+30
|\ \ \ \ | | | | | | | | | | | | | | | Merge-request: !2931
| * | | | FindOctave: Add target for octinterpPeter Stroia-Williams2019-02-082-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds the Octave::Octinterp target to make the octinterp library available without users having to resort to using the Octave_INTERP_LIBRARY variable.
* | | | | Merge branch 'ghs-updates' into release-3.14Brad King2019-02-081-1/+1
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | Merge-request: !2943
| * | | | | GHS: Document usage of GHS_NO_SOURCE_GROUP_FILEFred Baksik2019-02-081-1/+1
| |/ / / / | | | | | | | | | | | | | | | -- Also change variable name to CMAKE_GHS_NO_SOURCE_GROUP_FILE
* | | | | Merge branch 'fix-exclude-dir-with-iface' into release-3.14Brad King2019-02-082-0/+2
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | Merge-request: !2937
| * | | | Fix EXCLUDE_FROM_ALL on directory with an interface libraryBrad King2019-02-082-0/+2
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) we automatically forward the `EXCLUDE_FROM_ALL` to targets as they are created. This regressed support for interface libraries on which the property is not allowed. Skip forwarding the `EXCLUDE_FROM_ALL` property for interface libraries. It is not needed on them because they do not participate in the generated build system anyway. Fixes: #18896
* | | | VS: Fix nowarn compiler option to accept warning numbers.Wil Stark2019-02-073-0/+79
|/ / / | | | | | | | | | | | | | | | Warning disables are transferred to the VS IDE `<NoWarn>` node. Fixes: #18878
* | | Merge topic 'relax_CUDA_RESOLVE_DEVICE_SYMBOLS_constraints'Brad King2019-02-065-0/+151
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 850ef90a66 CUDA: Honor CUDA_RESOLVE_DEVICE_SYMBOLS for more target types Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Robert Maynard <robert.maynard@kitware.com> Merge-request: !2900
| * | | CUDA: Honor CUDA_RESOLVE_DEVICE_SYMBOLS for more target typesRobert Maynard2019-02-055-0/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | `CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and executable target types. This relaxation is to allow for better interoperability with linkers that automatically do CUDA device symbol resolution and have no way to disable it.
* | | | Autogen: Extend the SameName test with same name but different extension filesSebastian Holtermann2019-02-056-1/+68
| | | |
generated by cgit v0.12 at 2025-01-13 22:12:59 (GMT)