summaryrefslogtreecommitdiffstats
path: root/Tests/ConfigSources
Commit message (Collapse)AuthorAgeFilesLines
* Tests: Add case for source files named with CONFIG genexBrad King2020-05-181-0/+7
| | | | | | | This is now expected to work on all generators where the test runs. Recent ancestors of this commit fix the Visual Studio generator. Fixes: #20648
* cmGlobalGenerator: Fix CheckTargetsForMissingSources after refactoringBrad King2020-05-151-0/+14
| | | | | | | | | | | | Refactoring in commit 01b2d6ab74 (Modernize: Use ranged for-loops when possible, 2019-02-07, v3.15.0-rc1~575^2) accidentally changed a loop condition in this method from "keep iterating if srcs.empty()" to "stop iterating if srcs.empty()". Switch it back. The bug could only manifest in very subtle conditions in a multi-config generator. Add one such case to the test suite. Fixes: #20706
* INTERFACE_SOURCES: Fix per-config link libs on multi-config generatorsBrad King2020-05-122-1/+46
| | | | | | | | | | | | | | | | | | | | | In multi-config generators we memoize the computed set of source files for a target to avoid repeating the computation when the set does not depend on the configuration. We already track whether generator expressions in `SOURCES` or `INTERFACE_SOURCES` reference the configuration (`$<CONFIG:...>`). However, we previously forgot to track whether the set of libraries whose `INTERFACE_SOURCES` are considered depends on the configuration. This caused multi-config generators to use the first configuration's set of sources for all configurations in cases such as target_link_libraries(tgt PRIVATE $<$<CONFIG:Debug>:iface_debug>) where the `iface_debug` target has `INTERFACE_SOURCES`. Fix this by also tracking config-dependence of the list of libraries for evaluation of the list of source files. Fixes: #20683
* Tests: Enable ConfigSources test on every configurationBrad King2019-10-048-21/+69
| | | | | Revise the test itself to work in all configurations and verify that certain sources are only built by whatever configuration is tested.
* cmTarget: Don't allow relative paths in INTERFACE_SOURCESStephen Kelly2014-11-291-3/+3
| | | | | | | | | | | | | | | | | | | Follow the pattern of checks that are made for INTERFACE_INCLUDE_DIRECTORIES. Existence is already checked by cmSourceFile::GetFullPath. Add a check to disallow relative paths in source directories. Otherwise code such as target_sources(lib1 INTERFACE foo.cpp) would fail if consumed by a target in a different directory. Unlike the INTERFACE_INCLUDE_DIRECTORIES behavior, we don't care whether the entry comes from an IMPORTED target or not. In the include directories case, the directory for a non-imported target might not exist yet but might be created. In the sources case, a file which does not yet exist in the filesystem must be explicitly marked with the GENERATED property. Adjust existing tests and add a new test for the error.
* cmTarget: Allow transitive evaluation of SOURCES property.Stephen Kelly2014-04-025-1/+27
| | | | | | | Extend the cmGeneratorExpressionDAGChecker with an interface returning the name of the top target. Use that to determine when there is a DAG violation, as required by the RunCMake.Languages tests.
* cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-022-0/+14
Disallow the use of config-specific source files with the Visual Studio and Xcode generators. They don't have any way to represent the condition currently. Use the same common-config API in cmQtAutoGenerators. While it accepts config-specific files, it doesn't have to support multiple configurations yet. Loop over the configs in cmTargetTraceDependencies and cmGlobalGenerator::WriteSummary and consume all source files. Loop over the configs in cmComputeTargetDepends and compute the object library dependencies for each config.