GitLab

All these expressions work the same:
  "foo"
  ".*foo.*"
  "^.*foo.*$"

This assumes that the "Intel*" expressions were meant to be "Intel.*".

On OS X 10.9 the system libcurl has a different error message when
failing to connect:

  Failed connect to :21; Connection refused

Match this message to pass the test.

Extend the cmGeneratorExpressionDAGChecker with an interface
returning the name of the top target.  Use that to determine
when there is a DAG violation, as required by the RunCMake.Languages
tests.

Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.

Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.

Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.

Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.

Since commit 71b14dcb (Utilities/Release: Do not upload doc staging
tarball, 2014-02-26) the prefix upload_release.cmake computes does not
match any files when used with -DVERSION=master as has been done for the
nightly binary builds.  Since the version is not actually 'master'
anyway, change the nightly binary upload logic to explicitly pass the
destination directory.  Do not pass any VERSION so the default is taken
and matches the binaries.

Add an undocumented CMake_TEST_EXTERNAL_CMAKE option to name an external
CMake 'bin' directory.  Skip all main CMake binary builds and instead
configure the Tests directory to run using the external CMake provided.
This will provide a means to exercise the CMake test suite generating
for target platforms and compilers with which the CMake source does not
build.  That will allow us to raise the level of C++ features required
of a compiler to build our source while retaining tests for generating
projects with older compiler tools.

s/CMAKE_TEST_GENERATOR/CMAKE_GENERATOR/g

Remaining uses of the variable simply test its value so use
CMAKE_MAKE_PROGRAM directly instead.

Rename uses of the variable for specifying the make program used to
build test projects to CMake_TEST_EXPLICIT_MAKE_PROGRAM.

In the ExportImport, Fortran, and MacRuntimePath tests the
CMAKE_TEST_MAKEPROGRAM variable is used to pass an explicit request for
a CMAKE_MAKE_PROGRAM value to be used when building the inner projects.
Rename these use cases to CMake_TEST_NESTED_MAKE_PROGRAM.

Follow the convention of naming variables related to the CMake build
itself as "CMake_" rather than "CMAKE_".  While at it, consolidate the
code computing CMake_TEST_DEVENV to be more localized.

Now that we no longer support running tests using a different generator
we can trust the MSVC platform indicator directly.

Drop the option to test with a different generator and make program than
was used to build.  This was used only to test support for the Open
Watcom compiler which at one time could not build CMake.  Instead we
will allow CMake to be configured to skip building binaries and just run
the test suite using an external CMake (in a future change).

For now leave the two option variables hard-coded to the old option
defaults until code can be updated to stop using them.

KWSys now has its own dashboard and test clients that run on all the
machines where we test CMake.  We no longer need a test inside CMake to
test KWSys independently.

It is not showing modern practice, and is obsolete as documentation
after the rst documentation system and new content.

Commit 321e348e (QtAutogen: Use Qt 4 IMPORTED targets to find
executable locations., 2014-01-24) attempted to fix this problem,
but only solved it for a particular ordering of find_package for
Qt 4 and Qt 5.

Add a test to ensure that it works with both orderings.

The boolean variable CMAKE_SKIP_INSTALL_RULES
allows disabling generation of install rules for projects which don't
want them.

This has not been executed since it was added in
commit a984f325 (Introduce add_compile_options command., 2013-06-04).

The first regression resulted in endless looping due to unrun test
dependencies. The second regression prioritized all tests with dependencies
in serial test runs.

Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.

This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.

Transitively consume the property from linked dependents.

Implement configuration-specific support by following the pattern
set out for compile definitions and includes in cmQtAutoGenerators.

Implement support for origin-tracking with CMAKE_DEBUG_TARGET_PROPERTIES.

This is motivated by the needs of KDE, which provides a separate
translation system based on gettext instead of the Qt linguist
translation system. The Qt uic tool provides command line options
for configuring the method used to translate text, and to add an
include directive to the generated file to provide the method.

 http://thread.gmane.org/gmane.comp.kde.devel.frameworks/7930/focus=7992

Implement the interface to provide the uic options as a usage-requirement
on the KI18n target, as designed for KDE.

This variable can be useful in cross-compiling contexts where the
sysroot is read-only or where the sysroot should otherwise remain
pristine.

If the new CMAKE_STAGING_PREFIX variable is set, it is used instead
of CMAKE_INSTALL_PREFIX when generating the installation rules in
cmake_install.cmake.

This way, the CMAKE_INSTALL_PREFIX variable
always refers to the installation prefix on the target device, regardless
of whether host==target.

If any -rpath paths passed to the linker contain the CMAKE_STAGING_PREFIX,
the matching path fragments are replaced with the CMAKE_INSTALL_PREFIX.
Matching paths in the -rpath-link are not transformed.

The cross-prefix usr-move workaround is assumed not to require extension
regarding CMAKE_STAGING_PREFIX. The staging area is a single prefix, so
there is no scope for cross-prefix symlinks. The CMAKE_INSTALL_PREFIX
is still used to determine the workaround path, and that variable
remains the relevant one even if CMAKE_STAGING_PREFIX is used. If the
generated export files are deployed to the target, the workaround
will still be in place, and still be employed if required.

Do not pass the CMAKE_MAKE_PROGRAM cache entry to tests when using the
VS generators.  Allow them to pick the correct build tool automatically.

Also disable the MFC test if CMAKE_MAKE_PROGRAM is vcexpress.

Pass the CMAKE_TEST_MAKEPROGRAM, if any, to each test at CMake time in
the CMAKE_MAKE_PROGRAM cache entry.  Pass the CMAKE_TEST_MAKEPROGRAM
into the ExportImport, Fortran, and MacRuntimePath tests so that they
may do the same for the nested project configurations.

Now "ctest --build-and-test" can get the make program from the test
build tree cache, so drop the explicit --build-makeprogram.

Fix the condition that adds the test to check CMAKE_TEST_GENERATOR
rather than the tools used to build CMake.  Drop the test on Ninja
because the generator does not support subproject generation anyway.
Stop using the general build_generator_args and pass the
--build-generator options explicitly.  Also pass --build-makeprogram
explicitly when CMAKE_TEST_MAKEPROGRAM is available because there is no
CMakeCache.txt in the test project subdirectory from which to pick up
the make program.

Create a CTEST_TEST_DEVENV variable that is set to the
CMAKE_MAKE_PROGRAM used for Visual Studio 7, 8, and 9.  It will always
be either "devenv" or "VCExpress", and not "MSBuild".  Add the
VSExcludeFromDefaultBuild test only when this variable is set, and use
its value as the --build-makeprogram value.

More work will be needed later to restore the test on VS 10 and above
when devenv is available, but this is the simplest approach for now.

The test is only enabled on VS 10 and above, where the generators now
select for "ctest --build-and-test" the MSBuild tool by default.
Simplify the test configuration by dropping the --build-makeprogram
option and all the logic needed to compute its value.  The test will
automatically use MSBuild.

Collect all ctest_configure options in a list to configure it into the
test script.  Drop the unused -DCMAKE_MAKE_PROGRAM argument to ctest.

Create a "build_options" variable whose value is passed to every
"ctest --build-and-test" call through the --build-options argument.

Some extra options are for "ctest --build-and-test" directly, and others
are values for "--build-options".  Split these two roles out into two
separate variables and update existing uses.

Drop the -DCMAKE_TEST_MAKEPROGRAM argument because the value is not
used inside the test script.

Run the bootstrap script through "cmake -P" instead of
"ctest --build-and-test" so that we do not need to abuse
the --build-makeprogram option of the latter.

Also drop the temporary MAKEPROGRAM variable and the DART_ROOT special
case.  We never run dashboard clients with Dart anymore.

The ShellInstall test has long been replaced by the CMake.Install test.