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 '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.
This patch from Philip Lowman creates a REALPATH mode in the
get_filename_component command. It is like ABSOLUTE, but will also
resolve symlinks (which ABSOLUTE once did but was broken long ago).
See issue #8423.
This patch from Philip Lowman teaches SystemTools::GetRealPath to deal
with paths that do not exist by dealing with the case that realpath
returns NULL. See issue #8423.
When testing whether to re-run CMake, a byproduct may be a symlink. If
so, the existence of the link is important rather than the link's
target. See issue #8465.
App Bundle and Framework directories, symlinks, and Info.plist files we
create during generation are byproducts, not outputs. We should re-run
CMake only when they are missing, not when they are old.
See issue #8465.
A cmXMLSafe constructor named its parameter 'str' which shadowed the
name of the 'str' method. This renames the parameter to avoid the
conflict warning.
A previous change accidentally added the MacOS content directory and
Info.plist files created for MACOSX_BUNDLE executables to the list of
CMake input files. This causes CMake to re-generate the project too
often. These items should be added to the list of CMake output files.
The patch used to fix this bug used SystemTools::GetRealPath which works
only for existing files. It broke the case of using the command
get_filename_component for a non-existing file. Also, it changed
long-standing behavior in a possibly incompatible way even for existing
files. This reverts the original fix and instead updates the
documentation to be consistent with the behavior.
On some compilers 'char' is signed and is therefore always equal to or
less than 0x7f. In order to avoid the compiler warning we perform the
comparison with an unsigned char type.
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.
The old install_files, install_programs, and install_targets commands
used to permit installation to the top of the prefix by specifying
destination '/'. This was broken in 2.6.0 to 2.6.2 by changes to
enforce valid destinations that did not account for this case. This
change fixes the case by converting the install destination to '.' which
is the new-style way to specify the top of the installation prefix.
The recent change to avoid expanding rule variables in informational and
'cd' commands broke the logical order in generation of preprocess and
assembly rules. This corrects the order.
During bootstrap we do not bother with rule hashing. This updates the
dummy implementation to account for the recent change in rule hash
method signatures.
Previously the makefile generator would expand rule variables even on
its progress and echo commands for object compilation rules (but not for
link rules). This fixes the implementation to only expand rule
variables on user-specified rules.
This simplifies computation of custom command rule hashes to hash
content exactly chosen as the custom commands are generated.
Unfortunately this will change the hashes of existing build trees from
earlier CMake versions, but this is not a big deal. The change is
necessary so that in the future we can make optional adjustments to
custom command lines at generate time without changing the hashes every
time the option is changed.
This teaches cmMakefile::GetProperty and cmake::GetProperty methods to
return NULL when the property name is NULL, making them more robust and
consistent with the behavior of cmTarget::GetProperty.
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.
The link_directories command treats relative paths differently from most
CMake commands. This notes the difference in the documentation.
See issue #8377.
When running in script mode it is possible to run multiple separate
dashboard submissions in one cmCTest instance. The recent refactoring
of file submission lists into parts failed to clear the submission lists
when starting a new dashboard (ctest_start or ctest_update). Only the
unused old submission set was cleared. This fixes the refactored
version to remove the old submission set completely and also clear the
part-wise lists.
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.
Isolation of policy changes inside scripts is important for protecting
the including context. This teaches include() and find_package() to
imply a cmake_policy(PUSH) and cmake_policy(POP) around the scripts they
load, with a NO_POLICY_SCOPE option to disable the behavior. This also
creates CMake Policy CMP0011 to provide compatibility. See issue #8192.
This teaches functions and macros to use policies recorded at creation
time when they are invoked. It restores the policies as a weak policy
stack entry so that any policies set by a function escape to its caller
as before.
This re-organizes the discussion of the policy stack in documentation of
the cmake_policy() command. The new organization clearer and easier to
extend with new information.
A 'weak' poilcy stack entry responds normally to queries. However,
setting a policy in a weak entry will recursively set the policy in the
next entry too. This also gives the internal interface to create a weak
entry the option to provide an initial PolicyMap for it.
This makes cmMakefile::PushPolicy and cmMakefile::PopPolicy private so
that any outside place that uses them needs to use the PolicyPushPop
helper in an automatic variable. We grant an exception to
cmCMakePolicyCommand so it can implement cmake_policy(PUSH) and
cmake_policy(POP).
This creates cmMakefile::PolicyPushPop to push and pop policy scope
automatically. It also enforces balanced push/pop pairs inside the
scope it handles.
This defines PolicyMap as a public member of cmPolicies. Its previous
role as a policy stack entry is now called PolicyStackEntry and
represented as a class to which more information can be added later.
The previous change to order projects in the VS IDE did not account for
duplicate target names (such as ALL_BUILD and ZERO_CHECK) among the
input set. While we suppress generation of the duplicate project
entries, we need to use a multiset to store ordered duplicates.
The previous change to make ALL_BUILD come first among targets did not
account for comparing the target name against itself. This led to an
invalid ordering of the target set. This change fixes it.
This teaches the VS IDE generators to write ALL_BUILD into solution
files first so that it is always the default active project. Previously
it was first only if no target name sorted lexicographically earlier.
See issue #8172.
Our implementation of the feature to pull in dependent targets in VS
solution files for subprojects caused the order of project files in the
solution to be arbitrary (based on pointer value in the representation).
Target ordering in solution files is important to prevent unnecessary
changing of the files and because the VS IDE selects the first project
listed as the default active target. This change restores lexicographic
order by target name.
If a logical block terminates with mismatching arguments we previously
failed to remove the function blocker but replayed the commands anyway,
which led to cases in which we failed to report the mismatch (return
shortly after the ending command). The recent refactoring of function
blocker deletion changed this behavior to produce an error on the ending
line by not blocking the command. Furthermore, the function blocker
would stay in place and complain at the end of every equal-level block
of the same type.
This teaches CMake to treat the begin/end commands (if/endif, etc.) as
correct and just warns when the arguments mismatch. The change allows
cases in which CMake 2.6.2 silently ignored a mismatch to run as before
but with a warning.
This centralizes construction of the error message for an unclosed
logical block (if, foreach, etc.). We record the line at which each
block is opened so it can be reported in the error message.
This uses a stack of 'barriers' to efficiently divide function blockers
into groups corresponding to each input file. It simplifies detection
of missing block close commands and factors it out of ReadListFile.
Previously cmTarget::GetLocation and cmTarget::GetFullPath would return
for Mac AppBundles the top-level bundle directory but without the .app
extension. We worked around this at the call sites. This fixes the
methods and removes the work-arounds. See issue #8406.
When a function blocker decides to remove itself we previously removed
it at every return point from the C++ scope in which its removal is
needed. This teaches function blockers to transfer ownership of
themselves from cmMakefile to an automatic variable for deletion on
return. Since this removes blockers before they replay their commands,
we no longer need to avoid running blockers on their own commands.
Previously bad arguments to an if() or elseif() would cause some
subsequent statements in the corresponding block to execute. This
teaches CMake to stop processing commands with a fatal error. It also
provides context to bad elseif() error messages.
Recently we taught find_package to re-find a package configuration file
if it is given a wrong answer. This fixes the documentation to reflect
the change.
The documentation of cmake_policy PUSH and POP states that they must
always match. Previously we enforced this only for the top scope of
each CMakeLists.txt file. This enforces the requirement for all files.
This creates the variable CMAKE_VERSION containing the full version of
cmake in "major.minor.patch" format. It is particularly useful with the
component-wise version comparison provided by the if() command.
This uses an automatic variable to push and pop variable scope inside a
function call. Previously if the function failed its scope would not be
popped. This approach guarantees a balanced push/pop.
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.
This introduces the name "part" to denote a portion of the testing and
submission process performed by ctest. We generalize the boolean
indicating whether each part is enabled into a structure to which more
information can be added later. We provide bi-directional mapping
between part id and part names.
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.
As it is today the generator creates linked resources to
LIBRARY_OUTPUT_PATH and EXECUTABLE_OUTPUT_PATH if they are not a
subdirectory of the binary dir, so that the IDE can detect the
Binaries (this was addressed previously as a result of a bug report).
Reduces code redundancy by encapsulating common behaviour for
LIBRARY_OUTPUT_PATH and EXECUTABLE_OUTPUT_PATH in AppendLinkedResource.
Addresses the two new variable names for these locations,
CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_RUNTIME_OUTPUT_DIRECTORY respectively.
Finally, it is addressing a bug in the current code for relative paths
in these variables. If it is a relative path to the binary dir, the
IsSubdirectory call returns false and so it creates the linked
resource. The created linked resource produces an error in the Eclipse
IDE because the IDE expects it to be a full path. The patch now
addresses this by concatenating the binary dir if it is a relative
path.
The Generator="ctest..." attribute of Site elements in CTest-generated
XML files was missing a newline, causing the next attribute to appear on
the same line. This adds the newline.
The test is supposed to terminate quickly when its child crashes, but
that seems to take over 10s on busy systems. This extends the test's
timeout to 30s to help it pass when running on a busy system.
to by the Foo_DIR variable there is no FooConfig.cmake file, then instead of
abort and complain that the user should set or clear the Foo_DIR variables,
just search for the file and discard the old Foo_DIR contents
The tests succeed, ok by Brad.
Alex
When installing the main export file the install tree may be dirty. If
out-dated per-config files exist they may break the newly installed main
file which when it globs them. This teaches the installation script to
detect when it is about to replace the main export file with a different
one and cleans out any existing per-config files.
New method cmExportInstallFileGenerator::GetConfigImportFileGlob
computes the globbing expression that an installed export file uses to
load its per-configuration support files.
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.
Previously we stored a vector of tests to preserve their order.
Property set/get operations would do a linear search for matching tests.
This uses a map to efficiently look up tests while keeping the original
order with a vector for test file generation.
When CTest detects that a test is running its own executable it
optimizes the test by using an internal instance of cmCTest instead of
creating a new process. However, the internal instance was using cout
and cerr directly. This redirects the output to a string stream to
avoid direct display of the internal test's output.
When CMake 2.4 generates the build tree for CMake itself it asks the
built CMake to install itself using the rules that 2.4 generated. Since
the install rules use undocumented commands that are not compatible from
2.4 to 2.6 we need a special case to avoid failure. This sets a special
indicator variable in the install rules that enables a compatibility
hack to support the old install rule format.
The internal file(INSTALL) command argument parsing used several
booleans with at most one set to true at a time to track argument
parsing state. This refactors it to use one enumeration.
The get_target_property command contained some outdated documentation of
the LOCATION and TYPE properties. This removes it since they are now
documented in the properties list section of the documentation.
Previously we left the LOCATION property undefined for imported targets
since it should no longer be used for non-imported targets. However, in
the case we do not know the name of an available imported configuration,
it is more readable to get the LOCATION property than LOCATION_<CONFIG>
for a bogus configuration <CONFIG>. This enables LOCATION for imported
targets and returns an unspecified available imported configuration.
The FATAL_ERROR to cmake_minimum_required is useful for projects that
require 2.6 to convince CMake 2.4 to error out. This clarifies its
usefulness in the documentation.
When cmake_minimum_required is called with an unknown argument it should
not complain about it if the version specified is in the future. This
allows the proper error to be shown about the current CMake being too
old.
When computing runtime search path ordering a constraint exists when a
file that may be found by the runtime search exists in a directory other
than that containing the desired file. We test whether a potential
conflict is really the same due to a symlink. Recently the change to
cmFindLibraryCommand to load directory content created a case in which
the same-file check would be incorrectly skipped. This avoids skipping
the check.
On Windows the KWSys System package generates escapes for command-line
arguments. This fix enables quoting of the empty string as an argument.
This also adds a test to pass an empty argument to a custom command.
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.
When CTest encounters a test whose executable is the ctest executable
iteslf, it just invokes code inside itself to avoid starting a new
process. This fixes a null-pointer dereference in the logging code of
that case.
The command argument lexer was recently regenerated which erased some
fixes that had been applied directly to the output. This restores the
fixes and adds reminder notes in the generation instructions.
The command argument parser code is generated by bison. This change
restores some fixes previously applied to the generated output that were
destroyed by regenerating the parser source. This time the fixes have
been put in the input file so regenerating the parser will not destroy
them again.
We now search in
<prefix>/<name>*/
<prefix>/<name>*/(cmake|CMake)
when looking for package configuration files. This is useful on Windows
since the Program Files folder is in CMAKE_SYSTEM_PREFIX_PATH. These
paths are the Windows equivalent to the Apple convention application and
framework paths we already search. See issue #8264.
The $ENV{VAR} syntax permits access to environment variables. This
teaches CMake to recognize most characters in the VAR name since some
environments may have variables with non-C-identifier characters.
For bug #7191.
Improvements to the dialog that sets up the first configure.
Fixing the large size of it by breaking it up into a wizard.
Also incorporated suggestions from bug report.
When the find_package command loads a <name>-version.cmake file to test
the package version it must prevent the version file from affecting
policy settings. Therefore the policy settings must be pushed and
popped.
Generated cmake_install.cmake script code used MATCHES to compare
component names. This does not support characters considered special by
regular expression syntax in component names. This change uses STREQUAL
instead. See issue #8256.
When an object file directory is too deep to place an object file
without exceeding CMAKE_OBJECT_PATH_MAX, this issues a warning.
Previously we silently ignored the problem. See issue #7860.
When computing the maximum length full path to the build directory under
which object files will be placed, pass the actual path instead of just
its length. This will be useful for error message generation.
The CMAKE_<CONFIG>_POSTFIX variable and <CONFIG>_POSTFIX property were
not documented. This updates the CMAKE_DEBUG_POSTFIX and DEBUG_POSTFIX
documentation to refer to the more general variable/property. It also
clarifies that the variable is used as the property default only for
non-executable targets. See issue #7868.
This teaches find_package to search
<prefix>/(share|lib)/cmake/<name>*/
for package configuration files. Packages that do not already have
files in a <prefix>/lib/<name>* directory can use this location to avoid
cluttering the lib directory.
When the find_package command loads a module it sets several
<pkg>_FIND_XXX variables to communicate information about the command
invocation to the module. This restores the original state of the
variables when the command returns. This behavior is useful when a
find-module recursively calls find_package with NO_MODULE so that the
inner call does not change the values in the find-module.
When we install a target on Mac, we generate a call to install_name_tool to fix
install_name entries in the target for shared libraries it links. This change
makes the step ignore entries for imported targets since their install_name
will not change and cmTarget cannot produce a mapping for them. This fixes the
error
GetLibraryNamesInternal called on imported target: kdelibs
seen by kde folks.
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
Brad King
Ken Martin
Bill Hoffman
Alexander Neundorf
David Cole
Clinton Stimpson
Francois Bertel