ac9a5f4 ctest_build: Pass projectDir to GenerateBuildCommand
a6c0299 CTest: Simplify ctest_* command source/build dir lookup
1ca9318 VS: Add test for building MSBuild project in subdir
3cd4000 VS: Use .sln parser to build targets in subdirs with msbuild (#13623)
df035e4 VS: Create parser for Visual Studio .sln files
de8be9e Add projectDir parameter to GenerateBuildCommand
Commit b8259c3d (Centralize maintenance of usage requirement include
directories, 2013-04-29) changed the handling of the property.
Previously setting the property directly instead of via
target_link_libraries would not result in transitive include
directory handling.
This allows the ctest_build command's TARGET option to name a target
in a subdirectory and still build properly with msbuild.
Add test case covering use of ctest_build() with such a TARGET.
Add test covering cmGlobalGenerator::GenerateBuildCommand for VS
solutions with MSBuild and building a target defined in a subdirectory
and not part of ALL.
Create class cmVisualStudioSlnParser as a generic parser for Visual
Studio .sln files. Implement minimum functionality but keep class
extensible. Add tests for the class.
Use the suggestion from http://support.microsoft.com/kb/2262855 to escape
semicolons in preprocessor definitions for VS >= 10. Update the
COMPILE_DEFINITIONS documentation disclaimer list of known limitations
accordingly. Update our "Preprocess" test to cover the case.
Suggested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx
One is created by the compiler (/Fd) and the other by the linker (/pdb).
The two options should not specify the same file. Split them up.
In the VS IDE generators, simply drop ProgramDataBaseFileName to
take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb".
In the Makefile generators, set "/Fd" on the compile line to be
the directory containing object files (with a trailing slash the
compiler will add the "vc$(PlatformToolsetVersion).pdb" filename
automatically). Drop the /Fd option from the exe link command
line and add "/pdb" instead (already done for dll linking).
Update these rules for both MSVC and Intel tools.
Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC
libraries because the generated .pdb files are only from /Fd
and not real linker-generated .pdb files. Update documentation to
clarify that the PDB_* properties are only for linker .pdb files.
This regresses the PDBDirectoryAndName test for STATIC libraries.
Since it is not clear at this time what should be done for STATIC
library .pdb files, comment out the relevant portion of the test
and leave a TODO comment.
When called with a non-existent LHS target name the user may be trying
to add file-level dependencies. Clarify the error message to explain
the difference between target-level and file-level dependencies. Point
the reader at the commands and options needed for the latter.
The commit to add the INTERFACE_QT_MAJOR_VERSION in qtbase.git
is 14054d45 (Set the INTERFACE_QT_MAJOR_VERSION to 5., 2013-03-16)
which will be part of Qt 5.1.0.
If there is a Qt 5.0.3 release, there is no guarantee it will
contain that commit. Make sure such a Qt version does not fail
with this test if not.
We can do this check only if the TargetName is non-empty, which means
that we're evaluating INTERFACE_INCLUDE_DIRECTORIES from a linked
dependency which was set using target_link_libraries.
It is possible to have relative paths in INCLUDE_DIRECTORIES already
in CMake 2.8.10.2, so that part will require a policy to fix.
It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains
a directory which does not exist, which indicates a programmer error
by the upstream, or a packaging error.
One of the RunCMake.CompatibleInterface tests also needs to be updated
due to this change. Non-existant includes were used in the test, but
are not needed.
Check that source and binary directories are not part of the
INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets.
This is limited to directories which do not contain generator
expressions to evaluate. Such paths can only be checked at time
of use of the imported target, which will be done in a follow up
patch.
In particular, this checks that CTest's use of select() has a sufficient
file descriptor set size limit (FD_SETSIZE) to handle many child
processes at the same time. Running 20 tests requires more than 64
descriptors, the Cygwin default that we override.
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
We can't find both preprocessing expressions at once, because then
the BUILD_INTERFACE will always be favored if both are present, even
if INSTALL_INTERFACE appears first.
This was affecting the behavior of install(EXPORT) because the
INTERFACE_INCLUDE_DIRECTORIES contained entries like
/foo/include;$<INSTALL_INTERFACE:/bar/include>
As the INSTALL_INTERFACE always evaluates to '0', it always needs
to be preprocessed properly.
Since commit e03f83f3 (ProcessorCount test: fix path to cmsysTestsCxx
executable, 2013-01-24) the directory references a target that is not
built when BUILD_TESTING is OFF. It makes no sense to add tests without
BUILD_TESTING anyway.
While at it, use add_subdirectory instead of subdirs to add CMakeTests.
d90f49b CTest: Fail early without PROJECT_BINARY_DIR (#14005)
2e1c2bd build_command: Fail early without CMAKE_MAKE_PROGRAM (#14005)
4e5cb37 Refactor RunCMake.build_command test to allow more cases
Do not use PROJECT_BINARY_DIR before it is defined. If it is not
defined when needed, fail with an error message suggesting that the
project() command be invoked first.
If CMAKE_MAKE_PROGRAM is not set fail with an error message instead of
crashing. Suggest calling project() or enable_language() first to
ensure that CMAKE_MAKE_PROGRAM is set.
Move the ErrorsOFF/ON common logic from CMakeLists.txt into an
ErrorsCommon file to allow other test cases to be added that do not use
the Errors test logic.
Commit 79568f95 (automoc: Add source file to target early to set the
linker language, 2013-02-20) changed automoc initialization to a two
step process. In the first step, the generated source file was added
to the target, which allows the link language to be determined.
However, this bypassed the check for the availability of Qt itself.
At build-time the automoc file could not be generated because the moc
tool was not available to create it.
The solution is to only add the automoc file to the target if Qt is
found.
The CMake language implicitly flattens lists so a ";" in a list element
must be escaped with a backslash. List expansion removes backslashes
escaping semicolons to leave raw semicolons in the values. Teach
ExternalData_Add_Test and ExternalData_Expand_Arguments to re-escape
semicolons found in list elements so the resulting argument lists work
as if constructed directly by the set() command.
For example:
ExternalData_Add_Test(Data NAME test1 COMMAND ... "a\\;b")
ExternalData_Expand_Arguments(Data args2 "c\\;d")
add_test(NAME test2 COMMAND ... ${args2})
should be equivalent to
set(args1 "a\\;b")
add_test(NAME test1 COMMAND ... ${args1})
set(args2 "c\\;d")
add_test(NAME test2 COMMAND ... ${args2})
which is equivalent to
add_test(NAME test1 COMMAND ... "a;b")
add_test(NAME test2 COMMAND ... "c;d")
Note that it is not possible to make ExternalData_Add_Test act exactly
like add_test when quoted arguments contain semicolons because the CMake
language flattens lists when constructing function ARGN values. This
re-escape approach at least allows test arguments to have semicolons.
While at it, teach ExternalData APIs to not transform "DATA{...;...}"
arguments because the contained semicolons are non-sensical.
Suggested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
Extend the range of valid target names with the + sign. This character
can commonly be used for target names, such as those containing 'c++'.
Add a test but skip it for Borland and Watcom tools which do not support
the character.
Suggested-By: Benjamin Kloster
12fb50d GetPrerequisites: Add documentation for objdump
8eb2fe9 GetPrerequisites: Enable test for BundleUtilities on MinGW
33c94c8 GetPrerequisites: Add support for objdump
5260a86 GetPrerequisites: Move tool search paths up
Brad King
Stephen Kelly
Andreas Mohr
Petr Kmoch
Paul Kunysch
Jean-Christophe Fillion-Robin