We already recognize the Cray Fortran compiler id. Extract the version
number using the same predefined macros we already use for Cray C and
C++ compilers.
04a2a923 Help: Add notes for topic 'cpack-deb-new-component-vars'
57672e72 CPackDeb: CPACK_DEBIAN_PACKAGE_NAME documentation improvement
a45a4b2d CPackDeb: set package control field per component
a60574f1 CPackDeb: set priority control field per component
24012e3c CPackDeb: additional CPACK_DEBIAN_PACKAGE_SECTION documentation
47182ab8 CPackDeb: set section control field per component
Also add GTK2_TARGETS variable containing all imported targets.
Previously, the GTK2_LIBRARIES variable was filled with the paths to the
libraries, and only the GTK2_XXX_LIBRARY variables contained the imported
targets.
Multiple languages for SLAs and the SLA UI can be added via the CPack
variables CPACK_DMG_SLA_DIR and CPACK_DMG_SLA_LANGUAGES. For each
language defined in the languages variable, CPack will search for
<language>.menu.txt and <language>.license.txt in CPACK_DMG_SLA_DIR.
If the sla directory variable is not defined, the old behaviour using
CPACK_RESOURCE_FILE_LICENSE is retained.
There is the global CMAKE_DL_LIBS setting which can be used instead. There are
even platforms where this is either empty because those functions are part of
the libc or is called entirely different, so this code wouldn't work reliable
anyway.
In some cases, CMake returned the following error:
-- Checking for module 'foo'
-- Package 'foo' not found
When the actual error returned by pkg-config was:
Package 'bar', required by 'foo', not found
Now, the actual error is forwarded to the user.
-- Checking for module 'foo'
-- Package 'bar', required by 'foo', not found
For the standard case (i.e. the package was indeed not found), the
CMake error was:
-- Checking for module 'foo'
-- Package 'foo' not found
But it now prints:
-- Checking for module 'foo'
-- No package 'foo' found
The associated test was also updated. ${last} refers to the last
CLI argument.
We support setting CMAKE_OSX_SYSROOT to a symbolic value like "macosx".
Modules/Platform/Darwin-Initialize.cmake takes care of finding the
actual SDK path on disk. Use that result to set CPACK_OSX_SYSROOT
instead.
Set variables in the platform information modules to tell the Ninja
generator what deps type to use instead of hard-coding conditions in the
generator itself.
This module was added by commit v2.6.0~1489 (...supporting embedded
compilers..., 2007-07-02) to avoid needing to build the compiler id
detection source on toolchains that need special flags or linker files
to produce executables. Since then CMake has learned other ways to
identify such compilers (e.g. passing vendor-specific version flags and
checking for vendor-specific banners in the output). Furthermore, CMake
now detects a lot more than just the compiler id during language
initialization in order to support things like <LANG>_STANDARD and
COMPILE_FEATURES. Therefore CMakeForceCompiler is no longer a viable
approach because it skips such detection.
One remaining challenge to support toolchains that require special
linker files is to build the test for a working compiler, compiler ABI
detection binary, and other try_compile cases. This will have to be
worked out as such cases are encountered.
Unset CMAKE_MODULE_PATH before calling find_package(Git) to ensure we do
not get a project-provided FindGit module that may not provide the
GIT_VERSION_STRING that we need. We do not need to restore the value
explicitly because this occurs inside the _ep_add_download_command
function call scope.
Refactoring in commit v3.4.0-rc1~77^2~1 (ExternalProject: Use
GIT_VERSION_STRING instead of custom method, 2015-09-17) forgot
to update the variable name used in an error message.
If the automatically selected SDK is newer than the host OS version
and no deployment version has been set then adjust the deployment
version to the host OS version. Otherwise the user won't be able to
launch the executables on the build host.
This is for example a problem on a MacOSX 10.10 host with Xcode 7
which only provides a MacOSX10.11 SDK.
Starting with sigc++ 2.5.1, c++11 must be enabled in order to use
sigc++. The GTK2::sigc++ imported target will automatically enable the
required build flags in order to build with the version found on the
system.
1bf66fed FindOpenSSL: Search for unix-named libraries first on MinGW (#15765)
6b575dec FindOpenSSL: Tolerate tabs in header while parsing version (#15765)
Revert commit v3.4.0-rc1~10^2~2 (Features: Disable support for Oracle
SolarisStudio on non-Linux, 2015-09-29) and two follow-up commits.
The support of compile features and language standards on Orcale
SolarisStudio needs more investigation so for CMake 3.4 we should
just act as 3.3 did.
Generalize the change made by commit v2.8.10~228^2~4 (FindOpenSSL: find
cross-compiled OpenSSL from MinGW, 2012-07-23) to be used on builds
hosted on Windows too. When building for MinGW, consider library names
that come with MinGW before looking for the main Windows distribution of
OpenSSL.
2402bb8c Help: Document Windows 10 Universal Applications in cmake-toolchains(7)
1be2f12c VS: Add support for Windows 10 Universal (Store) Applications
2798dbda VS: Refactor indentation of LinkLibraryDependencies
8c426183 MSVC: Add system libs for WindowsStore on VS 2015
d1b87d72 VS: Select Windows 10 Store SDK and toolset for VS 2015
5fdf7594 Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
c824b23d Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
61bc0f73 Features: Disable support for Oracle SolarisStudio on non-Linux
3f077996 VS: Add support for selecting the Windows 10 SDK (#15670)
5dfc4c5f VS: Add hook to initialize Windows platform settings
61c472a2 cmSystemTools: Add VersionCompareGreater helper
Teach the VS 2015 generator to produce a WindowsTargetPlatformVersion
value. Use the CMAKE_SYSTEM_VERSION to specify the version and if not
set choose a default based on available SDKs. Activate this behavior
when targeting Windows 10.
Co-Author: Brad King <brad.king@kitware.com>
Teach CMakeDetermineSystem to check for a CMAKE_SYSTEM_VERSION setting
even when CMAKE_SYSTEM_NAME is not set. This will allow builds on the
host OS to target other versions of the OS without full cross-compiling.
When a user or a compiler wrapper adds '-static' to the compiler flags
then it will always link static binaries. Detect this from the compiler
id binary and disable TARGET_SUPPORTS_SHARED_LIBS. This will prevent
projects from accidentally adding shared libraries when the toolchain
does not support them. It also helps CMake avoid linking with flags
that require shared libraries to be supported.
On SunOS the -std=c++11 flag must be used for linking as well as
compiling. Until we implement support for this we cannot support
the CXX_STANDARD property except on Linux (where it was tested).
The latter is now the preferred URL for visiting cmake.org with a
browser. Convert using the shell code:
git ls-files -z | xargs -0 sed -i 's|http://www\.cmake|https://cmake|g'
fff9434d FindThreads: officially announce it works with only C++ enabled
66db914a FindThreads: fix printing a pointer value in test code
0b38424c FindThreads: make the call to try_run() work also if only C++ is enabled
9924a212 FindThreads: replace CheckIncludeFiles by CheckIncludeFile
a27bc0cc Check(Function|Library|Symbol)Exists: make it work if only C++ is enabled
7279f293 FindThreads: add simple testcase
This causes a warning in C mode, and entirely fails in C++ mode:
CMake/Modules/CheckForPthreads.c: In function ‘runner’:
CMake/Modules/CheckForPthreads.c:34:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
printf("%d CC: %d\n", (int)args, cc);
^
Use %p to print out a pointer value, which will not cause any problems.
While at it, also add a branch using CheckIncludeFileCXX. Also give a better
error message if no supported language is enabled. C++ support isn't working
yet, but it has never worked.
Commit 7235334a (Project: Determine default language dialect for the
compiler., 2015-09-15) introduced a mechanism to determine the default
dialect used for the running compiler. If conditions in
the <CompilerId>-<Lang>.cmake file are such that compile features for
that version of the compiler should be supported, the _DEFAULT_STANDARD
is set to the computed value.
However, the CMakeForceCompiler module allows users to bypass execution of the
compiler by CMake. In that case, do not set the _DEFAULT_STANDARD variable at
all, which effectively disables the compile-features where the module is used.
No compile features have ever been recorded where the module is used so no
functionality is lost.
If variable is set to TRUE, values of all variables prefixed with CPACK_
will be escaped so special characters such as dolar sign, quotes or
foreward slash will not be lost. By default variable is treated as set
to FALSE for back compatibility.
The cpack_encode_variables macro is changed into a function to remove
scope pollution. There should be no other effects.
Move detection over to the compiler id logic where we have already
constructed the list of compiler flags from ARG1 and CMAKE_<LANG>_FLAGS.
Pass the flags when we execute "cl" with "/showIncludes". Also pass "/c"
because we only need to compile, not link. Check the compiler process
exit code before trusting its output.
19934b67 FindPythonLibs: unset temporary _PREFIX variable
f8bc4e11 FindPythonLibs: Use python executable prefix as a hint
a9d32dff FindPythonLibs: Match include dir to library version
e134e53b Add support for *.manifest source files with MSVC tools
da00be63 MSVC: Rewrite manifest file handling with Makefile and Ninja
d488b5c9 Ninja: Always add OBJECT_DIR variable to link rules
6d620f5a VS: Add manifest tool settings to VS 8 and 9 project files
7c5b6ed5 ExternalProject: Use "git stash save --all" only if supported (#15722)
b04c3815 ExternalProject: Use GIT_VERSION_STRING instead of custom method
becb14c9 CPack/DEB: test preserve extra config file permissions
7044e8ee CPackDeb: use of libarchive and removal of fakeroot
415405a3 cmArchiveWrite: control user/group, permissions and recursive file adding
4f2ff601 Tests: Make RunCMake.CPack error messages more readable
81b748ae cmGeneratedFileStream: Fix spelling in comment
If PYTHON_EXECUTABLE is set, then we should look for the libs in the
same prefix, e.g. /usr/local/python -> /usr/local/lib, and on Win32
/Python34/python.exe -> /Python34/libs.
This commit ensures that FindPythonLibs has found the library before
before the search for the include dir begins. The library prefix and
version can then be used to find the matching include dir.
ea2db3bb FindPythonLibs: Fix OS X framework include directory search path
c57334fa FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input
2db092b1 FindPython{Interp,Libs}: Add versions 3.5 and 3.6
Classify .manifest sources separately, add dependencies on them, and
pass them to the MS manifest tool to merge with linker-generated
manifest files.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add a helper class private to "cmcmd.cxx" to contain the implementation.
Update the link logic to use the intermediate files directory for each
target to hold manifest and resource files before embedding into the
binary. Preserve the old behavior of placing the .manifest file next
to the binary when not linking incrementally even though it will be
embedded.
We use PATH_SUFFIXES to append "python<v>" to each candidate path. Do
not append it to the constructed list of python framework include
directories. Otherwise the combined path will never exist. Note that
the code doesn't yet try to match the suffixes "m" and "u" between the
executable, library, and include directory.
This cmake variable has been deprecated for over a decade, and using it
as an input could potentially cause unexpected results. We still need
to keep it as an output variable for compatibility though.
The calls to find_program now use NAMES_PER_DIR so that the first executable
(e.g. h5pcc) appearing on their PATH will get chosen. The HDF5_PREFER_PARALLEL
variable swaps the search order when it is set to true in the event that a
directory being search contains both h5cc and h5pcc.
When compiling with
LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
the compiler output includes a line like
COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' ...
that our link line regex matches due to an argument ending in "-ld".
Since it is not really the link line no implicit link information is
dectected. Exclude "VAR=..." lines from consideration as link lines to
fix this.
Since commit v3.1.0-rc1~635^2~7 (project: Add infrastructure for
recording CXX compiler features, 2013-10-17) we compile a test source to
a binary and then extract "<LANG>_FEATURES:..." strings from the binary
with the file(STRINGS) command. Add a newline at the beginning of the
string literal to be sure file(STRINGS) can extract the first entry as a
string independent of whatever else the compiler may put before the
storage it allocates for the literal within the binary.
04de9007 GHS: Fix generated file path slashes and quoting for 6.1.6
fbe0de92 GHS: Tell MULTI to delete .elf.ael file
63591b94 GHS: Find latest 'int' directory
Mangling is prevented by using a function instead of a macro for setting
default value of some CPack variables. Function is meant for internal use
in CPack.cmake only.
Old macro is deprecated but kept for backwards compatibility - was
intended for internal use only as it can't be used for CPack after
CPack.cmake script is included.
Patch removes local workarounds that were required by old macro,
fixes default setting of variables that by default inherit value from
another variable that already went through old default setting macro
(e.g. value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY caused error for
wrong escapes if CPACK_PACKAGE_INSTALL_DIRECTORY contained escaped
back slashes) and provides a test for correct escaping of characters.
9cdf6ef4 Swift: Add proper Swift compiler test
1aa29f0d Swift: Remove positive Swift language tests
d778a1c2 Swift: Require Xcode 6.1 and for MacOS X at least SDK 10.10
4da60024 Swift: Fix Compiler-Id detection for Swift 2
874a265c Swift: Make SwiftMix compatible with Swift 2
The documetnation of binutils:
https://sourceware.org/binutils/docs/binutils/ar-cmdline.html
suggests to use the parameters "q" and "c" in this order ("q" is
operation, and "c" is the modifier).
Suggested-by: Дилян Палаузов <dilyan.palauzov@aegee.org>
Generally for a module foo, SWIG generates (in Python mode)
an extension module _foo.so and a proxy Python module foo.py.
However, if -noproxy is specified, instead it builds only foo.so
(without the leading underscore). The custom command generated
by CMake correctly handles the removal of this underscore when
-noproxy is given; however, it still adds foo.py to the expected
outputs. This upsets build tools that expect foo.py to be generated
(for example, 'make' will run the SWIG command twice). Fix this
by removing foo.py from the set of extra generated files when
-noproxy is specified.
Add an OPENSSL_USE_STATIC_LIBS option to enable it. Adjust
CMAKE_FIND_LIBRARY_SUFFIXES to only look for .a and .lib files. Also
adjust the search paths on Windows for installer locations of static
libraries.
Provide each variant in ZLIB_LIBRARIES and ZLIB::ZLIB imported location
properties when one is found, while maintaining support for manually
setting the library via ZLIB_LIBRARY.
When the Fortran_HL component is specified, the hdf5_hl library is not included
in HDF5_LIBRARIES which causes a bunch of undefined references at link
time. This commit adds hdf5_hl to the list of libraries to search for when the
Fortran_HL component is specified.
Define HDF5_{Fortran_,}HL_COMPILE_LINE so that HDF5_{Fortran_,}HL_INCLUDE_DIR
and HDF5_{Fortran_,}HL_LIBRARIES are found when the macro is invoked for HL and
Fortran_HL components. (Use patch from debian cmake-data package.)
Starting with Xcode 7 the OSX and iOS SDKs contain only stub
files for dynamic system libraries. These stub files contain
some meta data and a list of exported sysbols in plain text.
They are handled by the toolchain like regular dylibs.
The handling of multilevel dependencies has been fixed in Visual Studio 2013.
The work around used for VS 2010 and VS 2012 does not work for VS 2013 any more.
Switch to normal object build rules for VS 2013 and newer.
Exposed by a CMP0054 warning with code like:
cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR)
project(MyProj NONE)
enable_language(C)
enable_language(CXX)
While at it, use STREQUAL for testing the compiler id against "GNU".
Suggested-by: Rolf Eike Beer <eike@sf-mail.de>
If CMAKE_MINIMUM_REQUIRED_VERSION is not set because no
cmake_minimum_required() call is present this line can lead to an error as that
string is empty so too few arguments are passed to if():
See also "/var/tmp/paludis/build/kde-krdc-15.08.0/work/build/CMakeFiles/CMakeOutput.log".
See also "/var/tmp/paludis/build/kde-krdc-15.08.0/work/build/CMakeFiles/CMakeError.log".
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:112 (elseif):
given arguments:
"VERSION_LESS" "3.1"
Unknown arguments specified
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:501 (_pkgconfig_parse_options)
/usr/share/cmake/Modules/FindOpenSSL.cmake:43 (pkg_check_modules)
This version is generated by the Windows Visual Studio
project files for unknown reasons, but is required to
pick up the debug version of the library created by
current versions of Xerces-C.
Since commit v2.8.7~31^2 (HP: Drive shared library linking with compiler
front end, 2011-12-12) the C compiler is used to link shared libraries
instead of calling the linker directly, so linker options need to be
wrapped as -Wl,-foo instead of -foo.
The compiler version reported since commit v2.8.2~1018 (CTest-side
support for compiler name and compiler version, 2009-10-12) only
reported the version of the compiler used to build CMake, and only
if it defined "_COMPILER_VERSION". Instead use the version of
the compiler used to build the project CTest is testing.
By default Mercurial command "clone" will implicitly call "update" with
the "default" branch after downloading the cloned repository. However
ExternalProject_Add() always generates a second "update" command after
cloning with a tag which is either specified or "tip" (equivalent to
"default" by default). Therefore ExternalProject will first clone then
update to default branch then update to another specified branch if
provided. This leads to potentially very long clone operation (in
particular when the repository default branch contain subrepos) which
can lead to transaction abort triggered by the server.
Simply use "hg clone -U" to avoid the implicit update during clone.
Our following call to "hg update" will take care of updating anyway.
Protobuf 2.6.x and lower do not use CMake (cmake is usable in Protobuf
3.x) but provide legacy Visual Studio projects files. Search their
output directories in 64-bit builds.
The Fortran compiler version detection infrastructure added by commit
v3.3.0-rc1~436^2~9 (Fortran: Add infrastructure to detect compiler
version, 2015-02-17) forgot to update CMakeFortranCompiler.cmake.in to
save the compiler version persistently as we do already in
"CMake{C,CXX}Compiler.cmake.in". Add the missing line now.
As dumpbin.exe is no longer reliable for gcc libraries on MinGW because
it crashes on many common libraries like libgcc_s and libgfortran it is
now necessary too resort to using objdump for DLL dependency walking.
Using objdump has a secondary problem in that it generates a lot of
output for large libraries and causes fixup_bundle() to take many
minutes to process what took fractions of a second with
"dumpbin.exe /dependents".
Add a 'grep' pre-filter in the execute_process() command pipeline to
reduce this output to a minimum for a several orders of magnitude speed
up. If grep is not available just use the full output.
As there does not seem to be a reliable way of detecting MinGW, callers
of fixup_bundle() may have to set the variable gp_tool to "objdump" if
dumpbin.exe is installed on the build machine to stop it using the
broken MS dumpbin.exe for library dependency walking.
Since commit v2.8.5~121^2~2 (FindMPI: Handle multiple languages,
2010-12-29) we called the GetPrerequisites is_file_executable function
but passed the name of a CMake variable instead of its value. Therefore
the function has always failed and caused the search for the compiler
name to run even with an absolute path. Switch to using if(IS_ABSOLUTE)
instead and drop use of GetPrerequisites.
Brad King
Domen Vrankar
Markus Rickert
Daniele E. Domenichelli
Simon Levermann
Raffi Enficiaud
Rolf Eike Beer
Joakim Andersson
Benjamin Chrétien
Marc Chevrier
Chris Davies
Gregor Jasny
Kevin Wojniak
Tamar Kranenburg
Wayne Stambaugh
Terrell Russell
Colin Tracey
Thijs Wenker
Francesco Romano
Gilles Khouzam
Stephen Kelly
Ben Boeckel
Ben Boeckel
Roman Donchenko
David Gobbi
Andreas Bergmeier
Paul Romano
Simon Richter
Geoff Viola
Ben Webb
Michael Scott
Yunqiang Su
Tony Kelman
Thorsten Glaser
Dominic Meiser
Matt McCormick
Kars de Jong
Roger Leigh
Roger Leigh
Konstantin Podsvirov
Chuck Atkins
Christopher Meng
Daniel Pfeifer
A. Joël Lamotte
Frank-Christian Otto
Bill Somerville