f0e298ad Help: Add notes for topic 'vs14-generator'
5c105140 Tests: Simplify LoadCommand tests
b1cbd577 FindBoost: Add -vc140 mangling for VS 14
bdc7d9c8 VS14: Fix Cl and Link flag tables as previous versions
d96b3f68 VS14: Generate flag tables from MSBuild v140 tool files
65624c39 VS14: Add Visual Studio 14 generator (#14982)
8635ac23 Tests/Preprocess: Remove unnecessary VS version tests
Call the generator "Visual Studio 14" without any year because this
version of VS does not provide a year in the product name.
Copy cmGlobalVisualStudio12Generator to cmGlobalVisualStudio14Generator
and update version numbers accordingly. Add the VS14 enumeration value.
Teach the platform module Windows-MSVC to set MSVC14 and document the
variable. Teach module InstallRequiredSystemLibraries to look for the VS
14 runtime libraries.
Teach tests CheckCompilerRelatedVariables, VSExternalInclude, and
RunCMake.GeneratorToolset to treat VS 14 as they do VS 10, 11, and 12.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Installing large directories, e.g., the output of a doxygen run, prints
one line per file resulting in too much noise in the build output. Add
an option to the install(DIRECTORY) command to not print anything upon
make install.
Extend the RunCMake.install test with cases covering MESSAGE_NEVER
behavior of the install(DIRECTORY) command.
Suggested-by: Stefan Eilemann <Stefan.Eilemann@epfl.ch>
Create a variable to allow users to control which installation
messages are printed. In particular, provide a "LAZY" setting
that prints "Installing" messages but not "Up-to-date" messages.
This is desirable for incremental re-installations.
Suggested-by: J Decker <d3ck0r@gmail.com>
Extend the cmake command-line interface to support
cmake -E env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
This will be useful to run processes with modified environments
without using a shell or a full "cmake -P" script to wrap it.
Extend the RunCMake.CommandLine test to cover success and failure cases.
Inspired-by: Jonathan Bohren <jbo@jhu.edu>
f0a0f3dc WCDH: Fix compiler id test for compatibility macros.
627ad96b Project: Detect other compilers before detecting Clang.
bc950169 WCDH: Remove noise from generated defines.
eecd93fc Features: Escape the COMPILE_OPTIONS for dialects.
The DECL part is redundant, and the language part is not needed. The
source language and context already determines the language, so there
is no need to repeat it in the define name.
The add_library(INTERFACE) and Interface Libraries documentation
list all the INTERFACE_* properties and target_* commands that
can be used to define the interface. Add INTERFACE_SOURCES
and target_sources() to these lists for completeness.
7eef823e Help: Add comma to assist parsing of ctest_build command docs.
5fb9b16d Help: Document that file(GENERATE) re-writes only when needed.
95135ac3 Help: Add missing external link marker.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Add support for Cobertura coverage files written by Java.
Add a test which uses the report from a Java run of Cobertura to calculate coverage.
In the documentation of CTEST_COVERAGE_COMMAND, give a sample .sh file to merge
the Cobertura .ser files and generate the XML report from the merged file.
In the ctest(1) manual and ctest_start() command documentation, convert
mentions of CTest Script variables to cross-references so they will be
rendered as links.
Explicitly specify the sequence of underline characters we use in the
CMake documentation. It is the same sequence as that suggested in the
Sphinx documentation, but we have our own descriptions.
This is the convention suggested in the Sphinx documentation and is
already used in several other places in the CMake documentation.
Update a few places where we were using other characters.
Explain how to use $<BUILD_INTERFACE> and $<INSTALL_INTERFACE> directly
in the documentation of the target_include_directories command and
INTERFACE_INCLUDE_DIRECTORIES target property. Otherwise readers need
to notice the link to the cmake-buildsystem(7) manual and find the
example in that to understand the need for these expressions.
Also fix the explanation in cmake-buildsystem(7) to not claim that
relative paths may be used inside a BUILD_INTERFACE expression.
Note in a few places of the cmake_policy() command documentation
that the cmake_minimum_required() command can set policies too.
Inspired-by: Peter Kümmel <syntheticpp@gmx.net>
Teach set_property and get_property an "INSTALL" property type to be
associated with install-tree file paths. Make the properties available
to CPack for use during packaging. Add a "prop_inst" Sphinx domain
object type for documentation of such properties.
Link to it from the documentation of related properties, variables
and commands.
Extend the cmake-developer(7) documentation with notes on
extending feature support for compilers.
Organize the documentation by sub-command to keep the signatures and
their descriptions nearby. Use inline and explicit reST markup. Revise
wording as necessary for the updated layout. Clarify behavior of the
file(GENERATE) command w.r.t. conflicting file names.
The ALLOWED_UNKNOWN_VARIABLE_READ_ACCESS access type was switched on an
undocumented variable and its lookup caused an unnecessary performance
impact. Remove it.
Allow setting build properties based on the features available
for a target. The availability of features is determined at
generate-time by evaluating the link implementation.
Ensure that the <LANG>_STANDARD determined while evaluating
COMPILE_FEATURES in the link implementation is not lower than that
provided by the INTERFACE of the link implementation. This is
similar to handling of transitive properties such as
POSITION_INDEPENDENT_CODE.
Add source file properties to control Xcode file type attributes:
XCODE_EXPLICIT_FILE_TYPE => explicitFileType
XCODE_LAST_KNOWN_FILE_TYPE => lastKnownFileType
Add a RunCMake.XcodeProject test to verify generated project content.
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
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.
ba387cb8 Help: Add notes for topic 'package-disable-registry'
be8ae960 Allow the Package Registry to be disabled (#14849)
d09fda5d Tests: Improve FindPackageTest for in-source builds
ac24a1c0 Tests: Improve FindPackageTest exported package version
When a project is packaged for redistribution the local package
registries should not be updated or consulted. They are for developers.
Add variables to disable use of package registries globally:
* CMAKE_EXPORT_NO_PACKAGE_REGISTRY that disables the export(PACKAGE)
command
* CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY that disables the User Package
Registry in all the find_package calls.
* CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY that disables the
System Package Registry in all the find_package calls.
Update documentation and unit tests.
Use the highest standard compile flags available if requested language
version is too new.
This supports use-cases like
set(CMAKE_CXX_STANDARD 14)
# Compiled with -std=c++11 with GNU 4.7, which has no -std=c++14
# or equivalent flag
add_executable(main main.cpp)
This can be used in combination with preprocessor defines which
communicate the availability of certain language features for
optional use.
This option was removed during conversion to the reStructuredText
documentation. Restore it. Process documentation starting at
Help/index.rst so that all manuals are included in the output.
Warn project developers at runtime that the module should not be used
anymore. Issue the diagnostic only when the project requires a new
enough CMake to use the alternative. Honor the
CMAKE_(ERROR|WARN)_DEPRECATED settings.
Allow directories in the source tree or build tree only if the
install tree is a subdirectory of the source tree or build tree,
as appropriate.
Re-use the test files in the RunCMake.include_directories test
to run in multiple scenarios. Bump the required CMake version
in the test to 3.0 to ensure that the new policy warnings are
emitted correctly.
Expect cxx_variadic_templates to implement N2555.
N2555 is essentially a bugfix and predates most compiler releases which
aimed to experimentally support variadic templates.
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.
Extend the interface of the target_compile_features command with
PUBLIC and INTERFACE keywords. Populate the INTERFACE_COMPILER_FEATURES
target property if they are set. Consume the INTERFACE_COMPILER_FEATURES
target property from linked dependent targets to determine the final
required compiler features and the compile flag, if needed.
Use the same pattern of origin-debugging which is used for other
build properties.
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.
Use the contents of it to upgrade the CXX_STANDARD target property,
if appropriate. This will have the effect of adding the -std=c++11
compile flag or other language specification on GNU when that is
needed for the feature.
Add a feature test using the compiler macros and the preprocessor to
determine available features.
Add a CMAKE_CXX_COMPILE_FEATURES variable which contains all features
known to the loaded compiler, and a CMAKE_CXX_KNOWN_FEATURES variable
containing all features known to CMake. Add language standard specific
variables for internal use to determine the standard-specific compile
flags to use.
This will be extended to other languages in the future. Follow-up
commits will add features which will be recorded by the feature test.
Brad King
Stephen Kelly
Joseph Snyder
Peter Kümmel
Nils Gladitz
Rolf Eike Beer
Ben Boeckel
Daniele E. Domenichelli