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.
-remove the unscriptable commands also from the cpack cmake
-use CPACK_PACKAGE_CONTACT in CMakeCPack.cmake, it's used in the nsis and
the deb generator
-make set_properties() scriptable
-use a non-const char array for adding the python modules
Alex
as discussed with David. This also gives a better ctest man page with just
the commands you should actually use in ctest scripts.
Until now these commands were more or less executed, but e.g. add_executable() didn't create an executable, project() failed with an
error. Now you get an error instantly if using one of these commands.
Alex
-add a RESULT_VARIABLE to INCLUDE()
-add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain
-have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system)
-use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to
run the executables if they have a different suffix because they are
probably crosscompiled, but nevertheless it should be able to find them
-make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE
-support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.)
-move ranlib on OSX from the file command to a command in executed in cmake_install.cmake
-add support for stripping during install in cmake_install.cmake
-split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools
-remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms
-create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these
-add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a
list of directories which will be prepended to all search directories, right
now as a cmake variable, turning it into a global cmake property may need
some more work
-remove cmTestTestHandler::TryExecutable(), it's unused
-split cmFileCommand::HandleInstall() into slightly smaller functions
Alex
Brad King
Bill Hoffman
David Cole
Alexander Neundorf
Ken Martin
Andy Cedilnik