When doing something like ctest -j8, the FindDoxygen.SimpleTest
test case would execute multiple doxygen sub-tests that then try
to create/write to the same output directory.
Both set_source_files_properties() and set_property(SOURCE) now accept
two new optional arguments: DIRECTORY and TARGET_DIRECTORY.
The DIRECTORY option takes a list of relative or absolute paths
pointing to processed source directories (add_subdirectory was
already called on them).
These paths specify directory scopes where the source file properties
will be set. Previously the scope was always the currently processed
source directory.
Similarly TARGET_DIRECTORY takes a list of targets, whose source
directories will be used as the list of scopes where to set the
source file properties.
get_property() and get_source_file_property() also get the same
new arguments, except only one value can be specified instead
of a list.
Fixes: #20128
6c5d4522bc INTERFACE_SOURCES: Fix per-config link libs on multi-config generators
8daa140c6a cmGeneratorTarget: Factor evaluated target prop entries into struct
fcd1a1a920 cmGeneratorTarget: Track when the set of link libs is config-dependent
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4740
Some RunCMake tests fail with this warning due to extra stderr content:
warning: this old-style function definition is not preceded by a prototype
Convert `foo()` to `foo(void)` in `.c` sources of affected tests.
Update the documentation (Squish 4 is from 2010, so people are likely
using something newer) and let squish_add_test call either the v3 or v4
macro based on the detected Squish version.
This cannot break things, since mixing incompatible versions would not
have worked before.
Windows has .exe in the target name, but Squish only uses the name without extension
which makes things a lot easier when running tests on several platforms.
Discovered when coming back to Windows and doing a fresh build and suddenly the
binary to be tested was no longer found due to the name mismatch.
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
Report in `cmLinkImplementationLibraries` and `cmLinkInterfaceLibraries`
whether the list of libraries depends on a genex referencing the
configuration. We already track whether a genex references the head
target.
Craig Scott