GitLab

Teach the project() command to recognize an optional "LANGUAGES"
keyword after the project name and prior to the list of languages.
Do not allow multiple copies of the keyword.  If the keyword is
specified and no languages are listed, imply NONE.

Define a new 'CMAKE_CONFIGURE_DEPENDS' directory property that projects
can use to specify input files to the CMake configuration process.
Extend the RunCMake.Configure test to verify that the build system
re-runs CMake when this input changes.

Extend the RunCMake.Configure with a case to verify that the CMake
configuration process does not immediately re-run the first time that
the generated build system is invoked.

Add a cmake command-line interface to provide a cross-platform 'sleep'.

The logic added by commit ffc0b5e4 (Overwrite the symlink if it already
exists, 2007-02-15) does not recognize and remove existing broken links
before replacing them.  Improve the logic to remove any existing
destination file or link (but not directory).  On failure, report an
error message explaining why the existing path could not be removed or
the new one could not be created.

Add a RunCMake.CommandLine test to cover 'cmake -E' cases.  Start with
test cases covering 'cmake -E create_symlink' behavior on UNIX platforms.

Add a 'run_cmake_command' function that can be used by tests to run a
given command-line and check the results rather than always running a
CMake configuration process.  This can be used in the future to test
'cmake -E' for example.

Added new policy CMP0046 which requires dependencies added by
add_dependencies() to actually exist.

Introduced in commit be0458c5 (InstallRules: added new variable to
disable generation of install rules, 2013-12-25).

Introduce policy CMP0045 to control this behavior.

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

The two most-recently-added policies were not tested for.

Stephen Kelly authored Dec 31, 2013 and Brad King committed Jan 07, 2014

This is consistent with other similar expressions such as PLATFORM_ID,
and makes the CONFIGURATION expression obsolete.

Fix an off-by-one error in
GeneratorExpressionContent::EvaluateParameters exposed by a unit test.

Remove the test for 'bad' nullary use of $<CONFIG>.

Add a unit test to verify that $<CONFIG> and $<CONFIGURATION> have
the same value.

Stephen Kelly authored Jan 06, 2014 and Brad King committed Jan 07, 2014

This content was copied from another test where both the Core and Gui
targets are used.

As a new feature it does not need to participate in CMP0024.

Store cmExportBuildFileGenerator instances which correspond to the
export(EXPORT) signature in a second map which does not own the
pointers.  This avoids the need to add cmExportBuildFileGenerator
and dependencies to the bootstrap system.

Document the valid signatures. Add a test for the IMPORTED GLOBAL
signature.

Test that it is an error to read a number-compatible property to
determine the link implementation.  An alternative would be to
consider the value to be "0", however, that is too arbitrary
given the use-cases of this feature.  Values from this feature may
be used in setting a define, where "0" may have special or invalid
meaning and should be explicit.

If the dependent target sets the property to boolean false, ensure
that that appears in the debug report.  Previously, the report
output contained whether the property was consistent among dependencies,
displaying 'TRUE', instead of the content of the property, which may
be 'FALSE'.

Return a std::pair from the consistentProperty method.  This makes
it possible to make the return value for string types easier to
reason about.  The return value of consistentProperty was previously
set to an empty static string to emulate a 'true' value for the caller
in commit 816b4a8a (cmTarget: Make consistentProperty
return consistent content., 2013-10-22).  The pair makes the
consistency result properly typed.

Don't refer to 'both', but a 'mixture'. List all compatible interface
property types possible.

Add another test for a mixture of three compatibilities.

Clinton Stimpson authored Dec 18, 2013 and Brad King committed Jan 02, 2014

Also adding documentation for CMAKE_MACOSX_RPATH, and improving
documentation for MACOSX_RPATH.

Teach the export command to handle export sets defined by invocations
of install(TARGETS ... EXPORT foo).  This makes maintenance of targets
exported to both the build tree and install tree trivial.

'a ALIAS' -> 'an ALIAS'

The INTERFACE_LIBRARY type does not have any LOCATION at all, so
return early from GetMappedConfig. GetMappedConfig is called from
two locations, one of which already pre-checks the INTERFACE_LIBRARY
case. Remove that pre-check and handle that case inside the method
instead.

Revert the origin-tracking infrastructure from commit 98093c45 (QtAutoUic:
Add INTERFACE_AUTOUIC_OPTIONS target property., 2013-11-20). Use the
compatibility-tracking for compatible strings instead.

If two different dependencies require different AUTOUIC_OPTIONS,
cmake will now appropriately issue an error.

Stephen Kelly authored Dec 02, 2013 and Brad King committed Dec 04, 2013

Commit 66b290e7 (export(): Process the export() command at generate
time., 2012-10-06 ) refactored export() so that it could evaluate
strings at generate-time. This was intended for evaluating target
properties, but that commit also removed a check for target
existence at configure-time. Restore that check and add a test for
this case.

Diagnostics which check the sanity of exported include paths
previously skipped over any path containing a generator expression.

Introduce a policy to issue an error message in such cases.

The export files created in the OLD behavior are not usable, because
they contain relative paths or paths to the source or build location
which are not suitable for use on installation. CMake will report an
error on import.

In code such as

 install(TARGETS ...
   INCLUDES DESTINATION $<FOO>include
 )

the generator expressions are evaluated at generate-time. Delay
determining whether each entry is a relative path until after
the generator expressions are evaluated. Such relative paths
are based relative to the CMAKE_INSTALL_PREFIX.

Test that no warning or error diagnostic is issued for 'good code'.

Nils Gladitz authored Nov 16, 2013 and Brad King committed Nov 19, 2013

Teach add_custom_target to check the policy too.  Extend the policy to
disallow reserved target names that we use for builtin targets like
"all".

Extend the RunCMake.CMP0037 test to cover these cases.

Historically these were both added for the Makefile and Visual Studio
generators, respectively.  Later the VS generators started using the
CMAKE_MAKE_PROGRAM cache entry to find the IDE build tool, and the
CMAKE_BUILD_TOOL was simply set as an alias.

Fix the documentation to explain that CMAKE_MAKE_PROGRAM is the modern
variable and that CMAKE_BUILD_TOOL is the compatibility alias, not the
other way around.  Replace uses of CMAKE_BUILD_TOOL with
CMAKE_MAKE_PROGRAM in CMake-provided modules.  Nothing needs to lookup
CMAKE_BUILD_TOOL in the cache, so simply set it as a normal variable.

Re-implement the build_command() command to use "cmake --build" instead
of generating a native build tool invocation directly.  This command
will internally invoke the proper native build tool.

This avoids requiring cmGlobalGenerator::GenerateBuildCommand to produce
a string so that it can be later refactored to produce a vector with no
quoting or escaping.  It will also allow us to later teach CMake to
delay the decision about which build tool to invoke until after the
project build system is generated to disk.  For example, on Visual
Studio 10 and above the preferred command-line tool is MSBuild, but we
need to fall back to devenv if the .sln has Intel Fortran .vfproj files.