summaryrefslogtreecommitdiffstats
path: root/Tests/CMakeCommands
Commit message (Collapse)AuthorAgeFilesLines
* cmGeneratorExpressionNode: implement `COMPILE_ONLY` genexRobert Maynard2023-05-042-0/+24
| | | | | | | | | This generator expression is the inverse of `LINK_ONLY` and only coveys usage requirements for the purposes of compilation. Its intended use is to avoid needing to export targets that do not have link usage requirements (e.g., header-only libraries) when used by another target. See: #15415
* Tests: Bump CMake minimum required in tests to 3.5Brad King2023-03-015-5/+5
| | | | | | | | | | | | | | | | | | | CMake 3.27 deprecates compatibility with CMake < 3.5. Update tests that do not cover older interfaces to avoid the deprecation warning. Follow the pattern from: * commit 7b07ccdd2b (Tests/*Only: Update cmake_minimum_required versions, 2020-06-15, v3.19.0-rc1~629^2~1) * commit 72e7c45e98 (Tests: Bump CMake minimum required in tests to 2.8.12, 2020-12-22, v3.20.0-rc1~224^2) * commit f6b4db365a (Tests: bump cmake_minimum_required version to 2.8.12, 2021-04-04, v3.21.0-rc1~372^2) Also remove explicit `cmake_policy` settings made redundant by the version.
* Xcode: Restore suppression of header mapsBrad King2023-02-174-0/+14
| | | | | | | | | | | | | | | | | | | | In commit 8527f42b96 (Xcode: Explicitly disable deprecated user include path feature, 2023-01-31, v3.26.0-rc1~7^2) we dropped the Xcode build setting `USE_HEADERMAP = NO` because Xcode 14's "Build Documentation" feature (`xcodebuild RUN_DOCUMENTATION_COMPILER=YES`) fails in some cases without header maps. However, enabling header maps causes Xcode to add `-iquote .../foo.hmap` and `-I .../bar.hmap` flags that can change the intended header file search order based on the contents of the header maps. This can break existing projects. Restore the `USE_HEADERMAP = NO` setting to fix the header file search order. Further investigation will be needed to resolve the problematic cases with the Xcode 14 "Build Documentation" feature. Meanwhile projects encountering such cases can set the `XCODE_ATTRIBUTE_USE_HEADERMAP` target property to `YES` themselves. Fixes: #24418 Issue: #24379
* target_link_libraries: Restore LINK_ONLY for multiple static lib dependenciesBrad King2022-03-163-0/+28
| | | | | | | | | | | | | | | | | Since commit c1e812ad4f (target_link_libraries: Improve tolerance of unquoted generator expressions, 2022-02-15, v3.23.0-rc2~11^2) we accumulate consecutive non-keyword arguments to recover an unquoted generator expression as a single entry. When given multiple consecutive non-genex library names, the grouping breaks our logic that expects each entry is either a raw target name or a genex. Revise the logic to only accumulate multiple arguments when they end inside a partial genex. This bug caused `target_link_libraries` to stop wrapping static library private dependencies in `$<LINK_ONLY:...>` for `INTERFACE_LINK_LIBRARIES` when multiple consecutive library names are given. Add a test case covering that behavior. Fixes: #23302
* target_link_libraries: Improve tolerance of unquoted generator expressionsBrad King2022-02-151-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of `INTERFACE_LINK_LIBRARIES` was a single string. If an unquoted generator expression passed to `target_link_libraries` contained `;` and became multiple arguments, they would all accumulate as a single `;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`. Since that commit, each argument to `target_link_libraries` is placed in `INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the case for `LINK_LIBRARIES`. That behavior change broke projects that were accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to produce complete generator expressions containing `;`. Teach `target_link_libraries` to accumulate consecutive non-keyword arguments into a single entry before placing them in `LINK_LIBRARIES` or `INTERFACE_LINK_LIBRARIES`. For example, treat `a b c` as if they were written as `"a;b;c"`. This restores the previously accidental support for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and also enables it for `LINK_LIBRARIES`. For now, do not drop the `target_link_libraries` documentation that recommends quoting generator expressions. Quoting is still important to populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good practice to keep generator expressions whole. Fixes: #23203
* IBMClang: Add support for IBM Open XL C/C++Aaron Liu2022-01-271-4/+4
| | | | Fixes: #22929
* Tests: Fix CMakeCommands.target_link_directories for regex chars in pathWenGe Wang2021-11-161-5/+5
| | | | Fixes: #22801
* LCC: Add policy CMP0129 regarding interpreting LCC as GNUmakise-homura2021-10-213-0/+12
| | | | | | | | | | Due to MCST LCC compiler identification is now changed to LCC, there should be a way for old projects to still identify it as GNU, as it was before. This commits adds the policy: CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU. This policy controls such a behavior. OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-153-10/+10
| | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* target_link_libraries: Restore transitive out-of-dir linkingBrad King2021-06-294-0/+16
| | | | | | | | | | | | Refactoring in commit 7f506b95a7 (cmGeneratorTarget: Refactor link item lookup, 2021-05-26, v3.21.0-rc1~103^2~4) accidentally dropped the persistent lookup scope tracking across multiple items that was added by commit f0e67da061 (target_link_libraries: Fix out-of-dir linking of a list of targets, 2020-01-14, v3.17.0-rc1~149^2). This broke a transitive out-of-dir linking case not covered by our test suite. Restore the scope tracking and add a test case. Fixes: #22363
* Tests: Bump CMake minimum required in tests to 2.8.12Chuck Atkins2020-12-235-4/+7
| | | | | | | Since 3.19, CMake generates a deprecation warning when using a minimum version less than 2.8.12. This eliminates those warnings generated during tests, which are typically hidden from the user and developer but are being generated nonetheless.
* target_link_libraries: Fix out-of-dir linking of a list of targetsBrad King2020-01-161-2/+3
| | | | | | | | | | | | | | In a case like target_link_libraries(targetInOtherDir PUBLIC "$<1:a;b>") then all entries in the list need to be looked up in the caller's scope. Previously our `::@(directory-id)` suffix would apply only to the last entry. Instead surround the entire entry by a pair `::@(directory-id);...;::@` so that the `::@` syntax can encode a directory lookup scope change evaluated as the list is processed. Fixes: #20204
* target_link_libraries: Fix out-of-dir calls with debug/optimized keywordsBrad King2020-01-101-1/+1
| | | | | | | | | | In commit a1ad0a699b (target_link_libraries: Allow use with targets in other directories, 2018-09-07, v3.13.0-rc1~94^2) we added use of `<...>` to encode a directory id, but the closing `>` can incorrectly terminate a surrounding generator expression early. Encode the directory id using `(...)` instead. Fixes: #20202
* target_link_libraries: Add FIXME comment for out-of-dir genex listBrad King2020-01-101-0/+3
| | | | Issue: #20204
* Revise include order using clang-format-6.0Kitware Robot2019-10-018-11/+5
| | | | | Run the `clang-format.bash` script to update our C and C++ code to a new include order `.clang-format`. Use `clang-format` version 6.0.
* Genex: CompileLang and CompileLangAndId now match against a list of idsRobert Maynard2019-06-035-0/+22
| | | | | | This allows for expressions such as: $<COMPILE_LANG_AND_ID, CXX, GNU, Clang>
* Genex: CompilerId now can match against a list of ids.Robert Maynard2019-06-033-2/+41
| | | | | This allows for expressions like: $<$<CXX_COMPILER_ID:Clang,GNU>:-DMY_PRIVATE_DEFINE>
* Genex: Add COMPILE_LANG_AND_ID generator expressionRobert Maynard2019-05-141-1/+1
|
* 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
* link_directories(): enhance capabilitiesMarc Chevrier2018-09-252-0/+34
|
* LINK_DIRECTORIES: Add new properties and commandsMarc Chevrier2018-09-253-0/+49
| | | | | | | | | | | | These new capabilities enable to manage link directories Two new properties: * target properties: LINK_DIRECTORIES and INTERFACE_LINK_DIRECTORIES One new command * target_link_directories(): to populate target properties Fixes: #17215
* Merge topic 'link-options'Brad King2018-09-171-0/+8
|\ | | | | | | | | | | | | 6da8b67c3f target_link_options: fix erroneous handling of BEFORE keyword. Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2384
| * target_link_options: fix erroneous handling of BEFORE keyword.Marc Chevrier2018-09-141-0/+8
| |
* | target_link_libraries: Allow use with targets in other directoriesBrad King2018-09-126-0/+84
|/ | | | | | | | | | | | | | | | | | | | | Previously the command did not allow naming targets on the LHS that were not created in the calling directory. Lift this restriction to enable more flexible use by projects. Targets named on the RHS will need to be looked up during generation in the scope of the call site rather than the scope of the LHS target. Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties to specify target names that need to be looked up in a directory other than that containing the target on which the property is set. Add minimal documentation of the syntax to help users that encounter it. Unfortunately CMake previously did allow such calls in the case that only `INTERFACE` libraries are specified, but those libraries would be looked up in the target's directory rather than the caller's. Add policy `CMP0079` to enable the new behavior with new lookup scope in a compatible way. Fixes: #17943
* LINK_OPTIONS property: add test for static library.Marc Chevrier2018-08-151-1/+8
| | | | | | | Check that property INTERFACE_LINK_OPTIONS is correctly propagated from static libraries. Issue: #18251
* Merge topic 'subdir_target_sources'Craig Scott2018-06-198-0/+135
|\ | | | | | | | | | | | | 316815e1f4 target_sources: Interpret relative paths as relative to the calling directory Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2128
| * target_sources: Interpret relative paths as relative to the calling directoryPatrick Stotko2018-06-188-0/+135
| | | | | | | | | | | | | | | | | | | | Previously the command considered non-absolute source file paths relative to the associated target on the LHS. This causes problems in incremental builds where files are added from subdirectories and forces users to workaround by manually converting to absolute paths. Change this to enable more intuitive usage by projects. Fixes #17981
* | LINK_OPTIONS: Add new family of propertiesMarc Chevrier2018-06-064-0/+50
|/ | | | | | | | | | | | | | This family enable to manage link flags Three new properties: * directory property: LINK_OPTIONS * target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS Two new commands * add_link_options(): to populate directory property * target_link_options(): to populate target properties Fixes: #16543
* Revise C++ coding style using clang-format-6.0Kitware Robot2018-06-0113-108/+108
| | | | | | | | | | | | Run the `clang-format.bash` script to update all our C and C++ code to a new style defined by `.clang-format`. Use `clang-format` version 6.0. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* add_compile_definitions: add new commandMarc Chevrier2018-04-202-0/+32
| | | | | | | This command manages preprocessor definitions at directory level and supports generator expressions. Fixes: #15374
* Features: Record C features for MSVCBrad King2018-03-291-3/+3
| | | | | | | | | The MSVC C compiler has no notion of C language standards or flags. Tell CMake to assume that all language standards are available. Record available C language features depending on the version of the compiler. Fixes: #17858
* Genex: Enable COMPILE_LANGUAGE for INCLUDE_DIRECTORIES with VS and XcodeBrad King2018-01-123-16/+20
| | | | | | | | | | | | | | | The set of compile flags used for a target's C and C++ sources is based on the linker language. By default this is always the C++ flags if any C++ sources appear in the target, and otherwise the C flags. Therefore we can define the `COMPILE_LANGUAGE` generator expression in `INCLUDE_DIRECTORIES` to match the selected language. This is not exactly the same as for other generators, but is the best VS and Xcode can do. It is also sufficient for many use cases since the set of include directories for C and C++ is frequently similar but may be distinct from those for other languages like CUDA. Fixes: #17435
* Genex: Enable COMPILE_LANGUAGE for COMPILE_DEFINITIONS with VS and XcodeBrad King2018-01-123-14/+30
| | | | | | | | | | | | | | | The set of compile flags used for a target's C and C++ sources is based on the linker language. By default this is always the C++ flags if any C++ sources appear in the target, and otherwise the C flags. Therefore we can define the `COMPILE_LANGUAGE` generator expression in `COMPILE_DEFINITIONS` to match the selected language. This is not exactly the same as for other generators, but is the best VS and Xcode can do. It is also sufficient for many use cases since the set of definitions for C and C++ is frequently similar but may be distinct from those for other languages like CUDA. Issue: #17435
* Genex: Enable COMPILE_LANGUAGE for COMPILE_OPTIONS with Visual StudioBrad King2017-11-203-14/+31
| | | | | | | | | | | | | | | | | | | Since commit v3.9.0-rc4~3^2~1 (VS: Fix target_compile_options for CUDA, 2017-06-21), the evaluation of `COMPILE_LANGUAGE` receives the proper language. The set of compile flags used for a target's C and C++ sources is based on the linker language. By default this is always the C++ flags if any C++ sources appear in the target, and otherwise the C flags. Therefore we can define the `COMPILE_LANGUAGE` generator expression in `COMPILE_OPTIONS` to match the selected language. This is not exactly the same as for other generators, but is the best VS can do. It is also sufficient for many use cases since the set of allowed flags for C and C++ is almost the same in Visual Studio. Furthermore, since the VS generator moves many of the flags to declarative `.vcxproj` elements, it will automatically avoid passing C++ flags for C sources. Issue: #17435
* CompileFeatures: Makes tests work with meta-feature onlyChuck Atkins2017-05-292-30/+45
|
* Tests: Ensure Solaris linker never sees empty contentsCraig Scott2017-05-181-1/+3
| | | | | Fixes the following tests on Solaris builds: wrapping, qtwrapping and CMakeCommands.target_link_libraries
* Tests: use cxx_auto_type only if actually availableRolf Eike Beer2017-01-251-1/+1
| | | | | The presence of CMAKE_CXX_COMPILE_FEATURES doesn't mean cxx_auto_type is always available.
* Revise C++ coding style using clang-formatKitware Robot2016-05-1630-107/+130
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Format include directive blocks and ordering with clang-formatBrad King2016-04-292-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sort include directives within each block (separated by a blank line) in lexicographic order (except to prioritize `sys/types.h` first). First run `clang-format` with the config file: --- SortIncludes: false ... Commit the result temporarily. Then run `clang-format` again with: --- SortIncludes: true IncludeCategories: - Regex: 'sys/types.h' Priority: -1 ... Commit the result temporarily. Start a new branch and cherry-pick the second commit. Manually resolve conflicts to preserve indentation of re-ordered includes. This cleans up the include ordering without changing any other style. Use the following command to run `clang-format`: $ git ls-files -z -- \ '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' | egrep -z -v '(Lexer|Parser|ParserHelper)\.' | egrep -z -v '^Source/cm_sha2' | egrep -z -v '^Source/(kwsys|CursesDialog/form)/' | egrep -z -v '^Utilities/(KW|cm).*/' | egrep -z -v '^Tests/Module/GenerateExportHeader' | egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' | xargs -0 clang-format -i This selects source files that do not come from a third-party. Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
* Tests: Do not try to use invalid "ld -v" flag on SolarisBrad King2015-03-311-1/+11
| | | | | Fix the CMakeCommands.target_link_libraries test to use "-V" instead of "-v" on Solaris because the latter does not exist.
* Genex: Allow COMPILE_LANGUAGE when processing include directories.Stephen Kelly2015-03-095-0/+37
| | | | Issue an error if this is encountered by an IDE generator.
* Genex: Allow COMPILE_LANGUAGE when processing compile definitions.Stephen Kelly2015-03-093-0/+56
| | | | Issue an error if this is encountered by an IDE generator.
* Genex: Enable use of COMPILE_LANGUAGE for compile options.Stephen Kelly2015-03-093-0/+56
| | | | | | Follow-ups will allow the use of the generator expression for compile definitions and include directories for non-IDE generators.
* Features: Extend concept to C language.Stephen Kelly2014-05-145-11/+73
| | | | | | | | | | | Add properties and variables corresponding to CXX equivalents. Add features for c_function_prototypes (C90), c_restrict (C99), c_variadic_macros (C99) and c_static_assert (C11). This feature set can be extended later. Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader to conditionally represent the c_restrict feature.
* Tests: Execute compile features tests unconditionally.Stephen Kelly2014-04-171-0/+8
| | | | Conditionally create a dummy test if there are no known features.
* Add target_compile_features command.Stephen Kelly2014-04-076-0/+49
| | | | | | | | | | | This can be used to set the compiler features required by particular targets. An error is issued at CMake time if the compiler does not support the required feature. If a language dialect flag is required by the features used, that will be added automatically. Base the target_compile_features command on cmTargetPropCommandBase. This gives us 'free' handling of IMPORTED, ALIAS, INTERFACE, non-compilable and missing targets.
* cmTarget: Don't update IMPORTED target compilation propertiesStephen Kelly2014-01-043-0/+21
| | | | | | The include_directories() and add_compile_options() commands should not append to the corresponding target property for IMPORTED targets. This is already the case for add_definitions().
* target_include_directories: Allow relative path with genexStephen Kelly2013-11-263-1/+9
| | | | | | | | | | | | | | | Treat paths which are relative and which contain a generator expression which is not at the beginning as relative to the source directory. This matches the behavior of paths which are relative but contain no generator expression at all. Previously this would generate a relative path with the IMPORTED target on export(), which would be a reported as a non-existent path on import. If used directly in the buildsystem, it would be reported as a relative path, which is also an error. There is no need for a policy in this case.
* Merge branch 'policy-CMP0022-fixes' into policy-CMP0022-fixes-for-masterBrad King2013-11-036-0/+56
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resolve conflict in Source/cmTarget.cxx by integrating the changes to the internal copy constructor from both sides. Also resolve a logical conflict by dropping the special case for INTERFACE_LIBRARY targets. Since cmTarget::SetMakefile already forces CMP0022 to NEW for such targets we need no special handling. Resolve conflict in Source/cmTargetLinkLibrariesCommand.h by dropping the documentation change. We will make the same change in the new location of the same documentation in a separate commit. Resolve conflicts in Tests/RunCMake/CMP0022/CMP0022-WARN-empty-old-stderr.txt Tests/RunCMake/CMP0022/RunCMakeTest.cmake by taking the side from the 'policy-CMP0022-fixes' branch.
| * CMP0022: Add test for target_link_libraries plain signatureStephen Kelly2013-11-026-0/+56
| |
generated by cgit v0.12 at 2025-01-18 05:41:25 (GMT)