summaryrefslogtreecommitdiffstats
path: root/Tests/AliasTarget
Commit message (Collapse)AuthorAgeFilesLines
* Clang: For MSVC ABI do not use modes older than C++14Brad King2019-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode, 2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that targets the MSVC ABI. However, Clang cannot compile with the MSVC standard library unless it runs in a mode aware of C++14 (since MSVC itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is set to 98 or 11, use C++14 anyway. Since Clang's default mode is aware of C++14, another option is to not add any flags for 98 or 11. However, if a future Clang version ever defaults to a higher C++ standard, setting the standard to 98 or 11 should at least not use a mode higher than 14. Also revert test updates from commit 4819ff9647 (Tests: fix failures with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that were meant to work around the standard selection problem. Fixes: #19496
* Tests: fix failures with gnu mode clang on windowsZsolt Parragi2019-05-241-1/+1
| | | | | | | | | Root causes were: * Using incorrect conditions (assuming MSVC-like command line mode) * Trying to compile the MSVC STL in C++11 mode, when parts of it require C++14 or enabling MS extensions in clang. * Missing flush in a testcase using stdout in a dll and a main part with static crt
* Revise C++ coding style using clang-format-6.0Kitware Robot2018-06-011-4/+4
| | | | | | | | | | | | 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.
* HP-UX: Drop support for building CMake on HP-UXBrad King2017-08-071-7/+0
| | | | | | | | CMake will soon require both C++11 and libuv to build. Neither of these works on HP-UX, so unfortunately we need to drop support for the platform until someone can get them working. Issue: #17137
* Merge topic 'use-string-append'Brad King2016-08-011-1/+1
|\ | | | | | | | | | | 7a649111 Use string(APPEND) in Tests 5d0d980d Use string(APPEND) in Modules
| * Use string(APPEND) in TestsDaniel Pfeifer2016-07-271-1/+1
| | | | | | | | | | | | | | Automate with: find Tests -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* | Do not report ALIASED_TARGET as always set (#15783)Gregor Jasny2016-07-161-7/+6
|/ | | | | | | | | The cmGetPropertyCommand::StoreResult expects NULL for unset properties. Make ALIASED_TARGET align with that expectation. Additional corrections to the unit tests are necessary because get_property removes variables for unset properties (in contrast to get_target_property which stores a -NOTFOUND value).
* Remove redundant arguments from fstream constructorsDaniel Pfeifer2016-06-142-4/+2
| | | | Don't pass the default value of the openmode parameter explicitly.
* Revise C++ coding style using clang-formatKitware Robot2016-05-166-6/+6
| | | | | | | | | | | | | 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.
* Merge topic 'fix-target-alias-in-subdir'Brad King2016-04-051-0/+5
|\ | | | | | | | | | | 0e44f489 Rename local target lookup methods to clarify purpose bc30f8b5 Fix lookup of an ALIAS target outside aliased target's directory (#16044)
| * Fix lookup of an ALIAS target outside aliased target's directory (#16044)Brad King2016-04-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactoring in commit v3.5.0-rc1~272^2~11 (cmTarget: Implement ALIAS in terms of name mapping, 2015-10-25) accidentally introduced logic that assumes ALIAS targets always reference targets in their own directory. Fix this and add a test case. The configure-step fix is that `cmMakefile::FindTarget` should not consider aliases. The purpose of this method is just to look up targets local to a directory. Since ALIAS and normal targets share a namespace we know a locally defined target will never collide with an ALIAS target anyway. The method has 3 call sites, and this change is safe for all of them: * `cmInstallCommand::HandleTargetsMode`: Rejects aliases before the call. * `cmFLTKWrapUICommand::FinalPass`: Should never have considered aliases. * `cmMakefile::FindTargetToUse`: Falls back to a global lookup anyway. The generate-step fix is that `cmLocalGenerator::FindGeneratorTarget` should not consider aliases. This method is the generate-step equivalent to the above. The method has 2 call sites, and this change is safe for both of them: * `cmInstallTargetGenerator::Compute`: Never uses an alias target name. * `cmLocalGenerator::FindGeneratorTargetToUse`: Falls back to global lookup. Reported-by: Matteo Settenvini <matteo@member.fsf.org>
* | Tests: fix AliasTarget building on Clang/C2Mariusz Pluciński2016-03-101-0/+7
|/
* Alias: Fix access at generate-time (#15832)Stephen Kelly2015-11-083-1/+13
| | | | | | | | | | | | Commit c389f8bb (cmLocalGenerator: Port Find method away from GetGeneratorTarget, 2015-10-25) ported the implementation of FindGeneratorTargetToUse away from the FindTargetToUse method, but neglected to handle alias targets. The latter method has a parameter to determine whether to include alias targets in the search, but as that is only needed at configure time, this generate-time equivalent does not need the condition.
* HP aCC: record compiler flag for Ansi C++98 support for version 3.80 onwardsRolf Eike Beer2014-04-251-1/+9
| | | | | | Old versions of aCC need a special compiler flag to get full C++98 template support as e.g. CMake itself or the Complex and ComplexOneConfig tests need. The same versions need a special flag to get a proper C++ library, too.
* get_property: Fix testing ALIASED_TARGET target property (#14670)Stephen Kelly2014-01-041-0/+22
| | | | | In the case where the argument is not an ALIAS, the variable should be set to a -NOTFOUND content.
* Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This target type only contains INTERFACE_* properties, so it can be used as a structural node. The target-specific commands enforce that they may only be used with the INTERFACE keyword when used with INTERFACE_LIBRARY targets. The old-style target properties matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for this target type. The name of the INTERFACE_LIBRARY must match a validity generator expression. The validity is similar to that of an ALIAS target, but with the additional restriction that it may not contain double colons. Double colons will carry the meaning of IMPORTED or ALIAS targets in CMake 2.8.13. An ALIAS target may be created for an INTERFACE library. At this point it can not be exported and does not appear in the buildsystem and project files are not created for them. That may be added as a feature in a later commit. The generators need some changes to handle the INTERFACE_LIBRARY targets returned by cmComputeLinkInterface::GetItems. The Ninja generator does not use that API, so it doesn't require changes related to that.
* Add the ALIAS target concept for libraries and executables.Stephen Kelly2013-08-027-0/+119
* The ALIAS name must match a validity regex. * Executables and libraries may be aliased. * An ALIAS acts immutable. It can not be used as the lhs of target_link_libraries or other commands. * An ALIAS can be used with add_custom_command, add_custom_target, and add_test in the same way regular targets can. * The target of an ALIAS can be retrieved with the ALIASED_TARGET target property. * An ALIAS does not appear in the generated buildsystem. It is kept separate from cmMakefile::Targets for that reason. * A target may have multiple aliases. * An ALIAS target may not itself have an alias. * An IMPORTED target may not have an alias. * An ALIAS may not be exported or imported.
generated by cgit v0.12 at 2024-11-08 13:02:25 (GMT)