The main svn update parsing loop in cmCTestUpdateHandler previously had
a logic error because the variable 'res' was not reset for each
iteration. For a locally modified file it would report the update info
for the previous non-modified file, or nothing if there was no previous
file. This fixes the logic by setting variable 'res' in both control
paths for each iteration. See issue #8168.
This renames the variable 'numModiefied' to 'numModified' to fix its
spelling. It also renames 'modifiedOrConflict' to 'notLocallyModified'
to describe its purpose (rather than the opposite of its purpose).
See issue #8168.
This teaches CTest to include source file labels in coverage dashboard
submissions. The labels for each source are the union of the LABELS
property from the source file and all the targets in which it is built.
Since CTest does not currently load configuration settings computed at
CMake Configure time while running dashboard scripts, the ctest_build
command must honor the CTEST_USE_LAUNCHERS option directly.
Currently CTest does not load configuration settings computed at CMake
Configure time when running a dashboard script. This adds a comment
describing refactoring that might help resolve the problem.
When we collect Build.xml fragments generated by 'ctest --launch', this
lexicographically orders fragments with the same time stamp on disk
instead of incorrectly dropping duplicates.
This defines a new CTest configuration variable CTEST_USE_LAUNCHERS.
When set to true it puts 'ctest --launch' in RULE_LAUNCH_* properties
and enables the CTest configuration option 'UseLaunchers'. Currently
this works only for Makefile generators.
This defines a 'UseLaunchers' CTest configuration option. When enabled,
CTest skips log scraping from the Build step output. Instead it defines
the environment variable CTEST_LAUNCH_LOGS to a log directory during the
build. After the build it looks for error-*.xml and warning-*.xml files
containing fragments for inclusion in Build.xml and submission.
This is useful in conjuction with 'ctest --launch' and the RULE_LAUNCH_*
properties to get reliable, highly-granular build failure reports.
cmCTestLaunch first used an empty initializer list to zero-initialize a
buffer, but this is not supported on older compilers. Instead we avoid
the need for initialization altogether.
This creates an undocumented 'ctest --launch' mode. It launches a
specified command and optionally records a failure in an xml fragment.
We will optionally use this in CTest's Build stage to record per-rule
build failure information when using Makefile generators.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
This gives the cmTarget instance for which custom command rules are
being generated to cmLocalUnixMakefileGenerator3::AppendCustomCommands.
It will be useful in the future.
This creates a new LABELS property for targets and source files. We
write the labels of each target and its source files in target-specific
locations in the build tree for future use.
This creates method cmTarget::GetSupportDirectory to compute a
target-specific support directory in the build tree. It uses the
"CMakeFiles/<name>.dir" convention already used by the Makefile
generators. The method will be useful for any code that needs to
generate per-target information into the build tree for use by CMake
tools that do not run at generate time.
On Windows the GetLongPathName API function does not work on some
filesystems even if the file exists. In this case we should just use
the original long path name and not the GetShortPathName result.
See issue #8480.
Brad King
Ken Martin
Bill Hoffman
Clinton Stimpson
Philip Lowman
Alexander Neundorf