Multiple libraries in a single buildsystem can be exported to multiple
export-sets.
If a library from one export set depends on a library from
another export set, the export logic generates a check in the targets
file to verify that the target in the other export set is found. That
check is executed at downstream-find_package-time.
However, a target may depend privately on a target in another export
set. In that case, the depend used to also be listed in the required
targets in the targets file. Change the export logic to ignore the
private link entries instead.
In commit 8fcf0ab0 (Add support for new Windows CE compiler, 2013-08-04)
we made corelibc conditional on the MSVC version, but the version value
was incorrect. Update it to use corelibc for VS 2008 and below.
Resolve conflict in Source/cmTestGenerator.cxx by taking "their" side
(test-property-genex). It already accounts for the lower-case change in
"our" side (generate-modern-style).
The old-style add_test() call does not support generator expressions at
all. This also applies to the properties for the test, but it is not
mentioned at all.
This is useful for cases like:
add_test(NAME mytest COMMAND mydriver $<TARGET_FILE:myexe>)
set_tests_properties(mytest PROPERTIES
REQUIRED_FILES "$<TARGET_FILE:myexe>"
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>"
)
In this example we require the actual test executable to exist to
run the test in addition to the test driver at argv[0]. Also the
$<CONFIGURATION> expression improves over \${CTEST_CONFIGURATION_TYPE}
because the latter is not normalized for case-sensitive filesystems.
Move property generation from GenerateScriptConfigs to separate copies
in GenerateOldStyle and GenerateScriptForConfig. This causes the
per-config tests generated for the add_test(NAME) signature to each get
their own test properties. This will allow us to later change the
property values based on the test configuration.
While at it, generate lower-case CMake code (e.g. set_tests_properties).
Inspired-by: Ben Boeckel <mathstuf@gmail.com>
State explicitly that the dependencies will build before the target.
Drop wording that may imply the opposite.
Suggested-by: Rob Stewart <robert.stewart@sig.com>
When FindHDF5 was first added in commit e6734068 (Add HDF5 find
module..., 2009-08-24) it contained a workaround for a bug in
SelectLibraryConfigurations that did not transform lists correctly.
That bug was fixed by commit 5797512c (SelectLibraryConfiguration:
generate correct output when input vars are lists, 2012-07-28). Then
refactoring in commit 04d4dc33 (SelectLibraryConfigurations: Use
-NOTFOUND instead of copying the vars, 2013-07-08) changed undocumented
behavior on which the original workaround relied. The result puts
entries like HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND in HDF5_LIBRARIES.
Fix this by dropping the original workaround since the underlying issue
has been fixed anyway. Use the HDF5_${LIB}_LIBRARY selected by the call
to select_library_configurations directly.
Teach cmListFileLexerDestroy to call cmListFileLexerSetToken with a NULL
token to free the token string buffer. Without this, if an error occurs
before the token cleanup happens when EOF is reached, then the token
string buffer may leak.
Only one argument is required. Also avoid using the same variable name twice in
the input list and follow the convention used elsewhere for optional arguments.
When RunCMake tests run during dynamic analysis, valgrind may add lines
of the form "==[0-9]+==..." to the output. Remove such lines from the
actual output before matching it against the expected output.
In commit 10bc50ea (Tests: ignore Guard Malloc messages in MemChecker
tests, 2013-05-13) we forgot to escape backslashes in the CMake language
to get them into the regex. Add them now.
Similar incomplete generator expressions are already tested
in the GeneratorExpression unit test, but those are executed
with add_custom_target. The generator expressions in the include
directories are run through the preprocessor, whereas the ones
run through add_custom_target are not.
In commit 2a797539 (FindPNG: improve library detection, 2013-07-27) we
split the search for PNG into separate PNG_LIBRARY_DEBUG and
PNG_LIBRARY_RELEASE variables. However, if a project or user sets the
old PNG_LIBRARY value we must honor it instead of searching.
While at it, mark PNG_LIBRARY_RELEASE and PNG_LIBRARY_DEBUG as advanced
and remove a stray debug message.
CMake's intended interface for linking to explicit object files (marked
with EXTERNAL_OBJECT) is that only those listed as target sources should
be linked. Drop FindCUDA's attempt to hide the .obj files from VS IDE
project files, which depends on VS-version-specific behavior of linking
custom command outputs that happen to be named "*.obj". CMake puts
external object files in a dedicated source group anyway.
The workaround currently present works fine without -O or with -O1, but fails
with -Os or -O2 and higher. Using -O2 is common e.g. in Gentoo, as resulting in
bugs like this:
https://bugs.gentoo.org/473276
Prevent the workaround for higher optimization levels to make bootstrapping
more likely to succeed.
This is still a workaround as ld still keeps crashing in some situations.
Stephen Kelly
Brad King
Eric NOULARD
Kitware Robot
Patrick Gansterer
Simon Levermann
Ben Boeckel
Alex Neundorf
Rolf Eike Beer