This factors parts of the svn update implementation that are useful for
any globally-versioning vcs tool into cmCTestGlobalVC. It will allow
the code to be shared among the support classes for most vcs tools.
The CTest version control refactoring broke the value returned for the
ctest_update command's RETURN_VALUE argument. The value is supposed to
be the number of files updated, but the refactoring accidentally made it
the number of locally modified files after the update.
This moves the filtering of source files to before the production of
coverage log files in order to avoid producing a CoverageLog-*.xml file
for 100 filtered-out files. The change greatly reduces the number of
submitted coverage files when using label filters.
When performing multiple ctest_coverage() commands in a single CTest
instance we need to clear the list of CoverageLog-*.xml files for
submission. Otherwise if the current coverage run produces fewer log
files than the previous run CTest will attempt to submit non-existing
files.
This teaches ctest_coverage() to remove any existing CoverageLog-*.xml
when it creates new coverage results. Otherwise the next ctest_submit()
may submit old coverage log files which unnecessarily.
This teaches CTest to process coverage information only for object files
in targets containing labels of interest. This change also improves
loading of global coverage information by globbing only in each target
support directory instead of the entire build tree.
This generalizes the previous CMakeFiles/LabelFiles.txt created at the
top of the build tree to a CMakeFiles/TargetDirectories.txt file. It
lists the target support directories for all targets in the project.
Labels can still be loaded by looking for Labels.txt files in each
target directory.
This adds cmCTestVC::InitialCheckout and uses it in cmCTestUpdateHandler
to run the initial checkout command. The new implementation logs the
command in the update log consistently with the rest of the new update
implementation.
This adds a new VCS update implementation to the cmCTestVC hierarchy and
removes it from cmCTestUpdateHandler. The new implementation has the
following advantages:
- Factorized implementation instead of monolithic function
- Logs vcs tool output as it is parsed (less memory, inline messages)
- Uses one global svn log instead of one log per file
- Reports changes on cvs branches (instead of latest trunk change)
- Generates simpler Update.xml (only one Directory element per dir)
Shared components of the new implementation appear in cmCTestVC and may
be re-used by subclasses for other VCS tools in the future.
This teaches cmCTestSVN::NoteNewRevision to save the repository URL
checked out in the work tree, the repository root, and the path below
the root to reach the full URL.
In cmCTestUpdateHandler, this factors out version control tool detection
from the monolithic cmCTestUpdateHandler::ProcessHandler to separate
methods. This also places priority on detection of the tool managing
the source tree since using any other tool will cause errors.
This moves the initial checkout code from the monolithic
cmCTestUpdateHandler::ProcessHandler to a separate method
cmCTestUpdateHandler::InitialCheckout.
Previously we pre-quoted the command line tool path. This avoids it by
quoting the command everywhere it is used, thus preserving access to the
original, unquoted command.
This adds documentation of the APPEND option to the configure, build,
test, memcheck, and coverage commands. The docs leave specific
semantics for the dashboard server to define.
This corrects the terse documentation and adds detail to the full
documentation of some commands. It also normalizes the layout of the
documentation string endings to make adding lines easier.
This removes generation of some Update.xml content that is not used by
any Dart1, Dart2, or CDash servers:
- Revisions elements
- Directory attribute of File elements
- File elements within Author elements
The content was generated only because the original Dart1 Tcl client
generated it, but the content was never used.
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.
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 '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 class provides easy syntax to efficiently insert blocks of data
into XML documents with proper escapes. It replaces the old
cmCTest::MakeXMLSafe and cmSystemTools::MakeXMLSafe methods which
allocated extra memory instead of directly streaming the data.
This moves the error/warning count summary printed by
cmCTestBuildHandler to after Build.xml is generated. Later we will
compute the counts during generation of the xml.
This divides cmCTestBuildHandler::GenerateDartBuildOutput into three
methods to generate the header, content, and footer components of
Build.xml files. It will allow the content generation to be replaced
later.
This refactors generation of <Test> element headers and footers in
cmCTestTestHandler and re-uses it in cmCTestMemCheckHandler. The change
removes duplicate code and enables the new <Labels> element for MemCheck
results.
We need to initialize cmCTestSubmitHandler on construction to make sure
all parts get enabled by default. The recent fix to re-enable all parts
on initialization broke submit-only operations because the handler did
not initialize on construction. This also removes duplicate
initialization code.
This splits the list of files for CTest to submit into those belonging
to each part. The set is recombined just before submission. Later this
will allow piecewise submissions.
The previous approach to handling of arguments to ctest_* commands
worked only for keyword/value arguments with a single value. This
refactors the approach to allow some commands to define alternative
argument forms.
This moves management of the LC_MESSAGES environment variable into an
automatic variable. Previously if an error occurred the original
environment value was not restored. This makes the fix to issue #5936
more robust.
When ctest --build-and-test runs the --test-command its output did not
quote the arguments of the command being tested making it difficult to
read. This adds the quotes. This also changes the wording of the
failure case to not sound like CTest could not run the executable when
in fact it ran and returned failure.
executing a ctest script so the search paths are fully set up and variables
like CMAKE_SYSTEM are available. This is useful e.g. for new-style ctest
scripting.
(these files are also loaded on startup by cpack, so now they behave
similar).
Hmmm, maybe they should be also loaded by cmake -P ?
Alex
The output of "cvs update" contains a line such as one of
cvs update: `foo.txt' is no longer in the repository
cvs update: foo.txt is no longer in the repository
cvs update: warning: foo.txt is not (any longer) pertinent
when file "foo.txt" has been removed in the version to which the update
occurs. Previously only the first case would be recognized. This fixes
the regular expression to match all these cases.
When the -C or --build-config option is used to specify the
configuration to be tested by CTest, do not override it with the
configuration in which CTest is built.
Brad King
Bill Hoffman
David Cole
Alexander Neundorf
Ken Martin