Fix the MUMPS coverage parser:
* Account for tabs after entry points
* Stop double incrementing lines that have explicit calls to the 0 line
* If a line has been previously marked as non executable, but then
contains a count, increment it an extra one to push it back into
the executable code set.
Add a custom routine and corresponding coverage files in the test case.
This file is smaller and has cmcov/mcov files that have data for only
that routine.
Provide a function to write a portable header to detect compiler
features. Generate a preprocessor #error for unknown compilers
and compiler versions whose features are not yet recorded. This
error condition might be relaxed in the future, but for now it
is useful for verification of expectations.
If creation of the global generator fails, return early with an error
message instead of trying to use the generator and crashing.
Add a CTestTestBadGenerator test to cover this case.
Reported-by: Mathieu Malaterre <malat@debian.org>
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747306
This can be used to set the compiler features required by particular
targets. An error is issued at CMake time if the compiler does not
support the required feature. If a language dialect flag is required
by the features used, that will be added automatically.
Base the target_compile_features command on cmTargetPropCommandBase. This
gives us 'free' handling of IMPORTED, ALIAS, INTERFACE, non-compilable
and missing targets.
Record the availability of this feature for GNU 4.8 on (UNIX AND
NOT APPLE) only. In the future, availability can be recorded for
earlier GNU, for other platforms and for other compilers. Initially
the affected configurations are as restricted as possible to allow
for easy testing while extending the features vector in only one
dimension.
The error message when using the set_property API directly is not
very good, but follow up commits will provide origin debugging of
the property and a target_compile_features command which will
provide a configure-time backtrace when possible.
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.
b633b263 CPackWiX: Fix test to build with expected config
191f25e2 stringapi: Prevent a NULL dereference in WiX
219d6ad6 speedup: Avoid excess iterator dereferences
caaad357 speedup: Cache strings for comparisons
7abf4e31 stringapi: Use strings for dependency information
94fc63e2 stringapi: Use strings for cache iterator values
85fc9f26 stringapi: Command names
6557382d stringapi: Use strings for program paths
1a1b737c stringapi: Use strings for generator names
24b5e93d stringapi: Use strings for directories
11ed3e2c stringapi: Add string overload for the Def struct
b3bf31a5 stringapi: Miscellaneous char* parameters
5af95c39 typo: Match argument name with the header
2b17626e stringapi: Pass strings as install directories in CPack
3def29da stringapi: Use strings for feature arguments
acb116e3 stringapi: Return a string reference for the configuration
...
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.
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.
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.
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 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.
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.
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.
Brad King
Joseph Snyder
Stephen Kelly
Rolf Eike Beer
Alex Ciobanu
Nils Gladitz