If this policy is WARN, then the ReplaceVariableInString is executed with both
the new algorithm and the OLD slow algorithm. The NEW algorithm should be used
wherever it works.
Support for C11's _Thread_local was introduced in GCC in the 4.9 series,
even though we make the C11 compiler flags available in CMake with GCC
>= 4.6.
FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build
to fail when using GCC < 4.9 and -std=gnu11:
/usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
extern _Thread_local const _RuneLocale *_ThreadRuneLocale;
Add a test for _Thread_local support and only build CMake itself with
C11 support if it works.
Bug: http://www.cmake.org/Bug/view.php?id=15741
Disable the CMake_INSTALL_DEPENDENCIES option by default and turn it on
explicitly in our packaging scripts. This simplifies packaging in
distributions that provide the dependencies for us without having to
install them. We only need 3rd-party runtime dependencies to be
installed for packaging with redistributable binaries.
The GNU 4.8 standard library's cstdio header is not aware that C++14
honors C11's removal of "gets" from stdio.h and results in an error:
/.../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace
Detect this problematic case and default to using C++11 instead of
C++14 for building CMake itself.
If CMake_NO_<LANG>_STANDARD is set, do not set CMAKE_<LANG>_STANDARD.
This will allow users to build with their own -std= flags without
CMake adding any itself.
Since jsoncpp 0.7.0 (2014-11-20) the upstream may provide a CMake
package configuration file such that find_package(jsoncpp) will find a
jsoncppConfig.cmake file. In order to avoid conflicting with this
(especially on case-insensitive filesystems), and since we always prefer
projects to provide package config files (that they maintain), it is
better to not provide FindJsonCpp publicly.
Move FindJsonCpp into a private source directory that is not installed
so that we can still use it for building CMake itself.
Reported-by: Ryan Pavlik <ryan.pavlik@gmail.com>
Move CMAKE_USE_OPENSSL and CURL_CA_BUNDLE up to the top of CMake so that
CMake's own sources can know their values. Add the CURL_CA_PATH option
at the top and honor it as part of the curl build.
This fixes several reported bugs about CMake not handling
non-ascii paths on Windows.
Practically, the use of some unicode characters may still
be limited by the build or compiler tools.
For example, a user may be limited by the build tools to
using characters within the Windows ANSI code page (which can
include non-ascii characters in the current system language).
Update json/json.h to account for our lack of autolink.h. Update
json/config.h to include KWSys Large File Support configuration so that
consistent stream libraries are used (on AIX with XL).
Add a cm_jsoncpp_reader.h header to include the CMake-provided copy of
the json/reader.h header from CMake sources.
Set CMAKE_C_STANDARD and CMAKE_CXX_STANDARD only if they are not
already defined. This will allow users to add the settings with
different values to their local cache (e.g. on the command line).
When CMake is built with CMake 3.1 or later, appropriate -std=
options will be added for GNU and Clang compilers while building
C and CXX code.
This allows taking advantage of 'hidden' language features such
as move-constructors, and allows the standard library to enable
the use of more-advanced features too, where available.
This does not change CMake host compiler requirements.
Set curl build options as needed for CMake rather than presenting them
to the user in the cache. Drop the CMAKE_BUILD_CURL_SHARED option for
now.
Change the curl library name to 'cmcurl'. Disable blocks of code within
curl CMakeLists.txt files that we do not need for CMake, but leave the
code in place to make merging with curl updates easier.
When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly
dereference or quote the variable. We want if() to auto-dereference the
variable and not its value. Also replace MATCHES with STREQUAL where
equivalent.
The CMAKE_SYSTEM_NAME is "CYGWIN", but we also define a variable
named "CYGWIN" to "1". Avoid allowing if() to expand the "CYGWIN"
string as a variable.
The CMake_TEST_EXTERNAL_CMAKE option added by commit 9608ef6f (Tests:
Optionally configure tests exclusively, 2014-03-03) is intended to allow
one to run the CMake test suite with a compiler that may not be
supported for hosting the build of CMake itself. However, we currently
use the CMake test infrastructure to test KWIML everywhere that CMake
supports. In order to continue testing KWIML even in places that CMake
itself does not build, include it even when testing an external CMake.
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.
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.
Always name the application bundle "CMake.app". Users can rename it
after installation if they wish. This is the typical approach used by
OS X applications, including Xcode. It allows CMake to be upgraded
without manually re-running CMake in every build tree to update the path
to CMake. It also makes the executable location in the CMake build tree
more predicatable.
Install the Help directory next to Modules to make it available in CMake
distributions. Use cmRST to read Help .rst documents and print them as
help output.
Add options
--help-manual-list
--help-manual
to list available manuals or print one of them. Implement the options
--help-commands
--help-modules
--help-policies
--help-properties
--help-variables
by mapping to the corresponding manual page. Implement the options
--help-command-list
--help-module-list
--help-policy-list
--help-property-list
--help-variable-list
by globbing the available Help .rst documents of the corresponding type
and reading their titles. Implement the options
--help-command
--help-module
--help-policy
--help-property
--help-variable
by globbing the matching Help .rst document(s) and printing them.
With our modern development workflow it is less likely a property will
be added to C++ code without documentation. This mode only existed to
support the DocTest which had very limited coverage of the properties
anyway.
Factor the CMAKE_DATA_DIR, CMAKE_DOC_DIR, and CMAKE_MAN_DIR selection
out of CMakeLists.txt and into a Source/CMakeInstallDestinations.cmake
script. Load the script from the original location of the code.
Cache the destination values as empty strings so we know if the user
sets them explicitly. If not, then compute defaults based on the
platform and full CMake version string. By not caching the versioned
defaults, we can change them in a single build tree as the version
changes.
Remove duplication of the install destination defaults from the
bootstrap script. Cache empty defaults there too. Parse from the CMake
code the default values to report in the help output. Keep the CMake
code in a structured format to make this reliable.
Move logic to compute CMake_VERSION out of the top-level CMakeLists.txt
file to a dedicated Source/CMakeVersionCompute.cmake module and include
it from the original location. This will allow it to be re-used.