In v2.8.12.1-654-g7621ad6 I added underscore prefixes to
CPACK_ADDCOMP_(STR|UNAME) to prevent them from being automatically
written to CPackConfig.cmake.
Do the same for CPACK_ADDGRP_(STR|UNAME) and CPACK_INSTTYPE_(STR|UNAME).
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. Fix the
separate compilation code path to not add its own quoting when the
VERBATIM option will be used.
The fix in commit v3.5.0-rc1~27^2 (FindPkgConfig: set standard variables
in the cache, 2016-01-20) added the wrong variable name to the cache.
The test was only testing that the cache variable existed, not that it
also had the correct value. Update the test to ensure that the cache
value matches the local variable value.
Reported-by: Bernd Lörwald
6a6e5d89 GenerateExportHeader: Allow common NO_DEPRECATED_MACRO_NAME for multiple libs
be5a8973 GenerateExportHeader: Do not define DEFINE_NO_DEPRECATED (#16022)
Previously we allowed this definition to persist outside our header.
This would cause conflicts across multiple such headers because the name
was always the same. Fix this by avoiding the definition altogether.
When system-provided packages are upgraded we must re-compile sources
depending on their headers. Use `-MD` instead of `-MMD` so that the
generated depfiles do not exclude system headers.
Suggested-by: Jussi Judin
If list of valid target architectures is empty for given SDK then there will
be no VALID_ARCHS build setting returned by Xcode. Return "" (empty string)
explicitly in this case. This may happens if CMAKE_IOS_INSTALL_COMBINED is ON
but only one architecture used in target.
Depending upon the configuration, certain components may or may not
be installed, for example Boost.Regex, but other components may
still have header dependencies upon these components which will
obviously fail to work. Since we can't make a sensible
determination with the hardcoded dependency information, we
choose to interpret these dependencies less strictly.
491b41dd Help: Add notes for topic 'vs-clang-cl'
ad6d27ac Tests: do not build PrecompiledHeader on Clang/C2
a0f0541f Tests: fix PDBDirectoryAndName on Clang/C2
3541af67 Tests: fix Plugin building on Clang/C2
1902c293 Tests: fix complexOneConfig building on Clang/C2
cab2ec11 Tests: fix Complex building on Clang/C2
ada3736c Tests: fix Module.GenerateExportHeader building on Clang/C2
123b7e13 Tests: fix AliasTarget building on Clang/C2
445d4d4b VS 14: Add flag map for -std= to CppLanguageStandard tag in project files
0a785eb4 Features: Clang has no cxx_decltype_incomplete_return_type in MSVC sim mode
2c2ec488 VS: in Clang/C2 toolset, setup correct compiler settings
37afe00f CMakeDetermineCompilerId: Add detection of clang.exe bundled with VS
Since commit v3.1.0-rc1~564^2 (OS X: Use -iframework for system
framework directories, 2014-05-05) we test the version of Clang is smaller
that 3.1 to see if it supports -iframework.
Considering that "iframework" support has been added in clang@r142418
(Frontend: Support -iframework.) prior to clang 3.1, this made sense.
That said, considering that support for multiple -iframework parameters
has been added later in clang@r164607 (-iframework should allow separate
arguments. ) prior to clang 3.2, this commit updates the check to enable
framework support only if version is >= 3.2
We originally deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19).
Then a use case was found to still require the module so the deprecation
was reverted for CMake 3.5 by commit v3.5.0-rc3~4^2 (CMakeForceCompiler:
De-deprecate until more use cases have alternatives, 2016-02-17). Since
then `CMAKE_TRY_COMPILE_TARGET_TYPE` was introduced to provide an
alternative solution for that use case. Deprecate the module again.
Canonicalize the input paths so we treat them both consistently,
in particular when comparing them via string operations. This
is needed for calls like
fixup_bundle("${CMAKE_INSTALL_PREFIX}/../test" ...)
Suggested-by: Benjamin Ballet <bballet@ivsweb.com>
Use recommended case for variable names. i.e. matching name of the
module as passed to `find_package`.
For backwards compatibility, the upper case versions of both input and
output variables are used and defined when appropriate. Skip this for
the _FOUND variable because FPHSA already does it. Skip this for the
_VERSION variable because that was recently added and never available
with the old name in a release of CMake.
Also detect the library version number. Provide results as variables
and as an imported target, LTTng::UST.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
When we check for a working compiler we print a message of the form:
Check for working <LANG> compiler: ...
At one time CMAKE_<LANG>_COMPILER was not well-defined for all
generators so we printed the generator name instead of the path to
the compiler. Nowadays we always know the compiler, so update the
message to print it unconditionally. This is more informative than
the generator name, especially when a toolset (cmake -T) is used.
Suggested-by: Gregor Jasny <gjasny@googlemail.com>
This is done the same way as for Eclipse: cmake tries to determine
the number of CPUs, and then adds the respective -jN to the make
invocations in the project file.
Alex
If CMAKE_INSTALL_RPATH is set and contains $ORIGIN then
dpkg-shlibdeps searches for the DEBIAN directory in order
to resolve $ORIGIN in the rpath to a directory. We need to
create the DEBIAN directory for this to work.
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. However,
this breaks the special `$(VCInstallDir)` placeholder used with Visual
Studio generators. Since we do not support preservation of such
placeholders with VERBATIM (see issue #15001) we must fall back to not
using VERBATIM when the placeholder is used.
A better fix would be to stop using `$(VCInstallDir)` and use the value
of `CMAKE_${CUDA_C_OR_CXX}_COMPILER` instead, but that will require
additional semantic and documentation changes. For now simply fix the
regression with the above approach.
Reported-by: Stephen Sorley <Stephen.Sorley@jhuapl.edu>
We deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19)
in order to determine whether anyone still has use cases that require
it. Indeed we still need to provide a way to work with toolchains that
cannot link binaries without special flags. Remove the deprecation
warnings until we can provide an alternative to the module for this use
case.
We use `sh wx-config` to launch the `wx-config` tool so that it can run
even on Windows. Since it is always a shell script its output may use
POSIX paths even on Windows. Use `cygpath` to convert to Windows paths.
Check found libraries version to match user required version.
Protobuf compiler executable version is checked to be aligned with found
libraries, raising a warning message otherwise.
CPACK_* variables expect component name in upper case.
CPACK_RPM_* variables expected component name to be
in same case as component name.
This patch adds support for CPACK_RPM_* variables with
upper case component names to match the convention with
CPACK_* variables and also preserves same case component
names for back compatibility.
The specific cause is when e.g.
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib
is detected by fixup_bundle. set_bundle_key_values() interprets this as
a framework, thus doing a string replace that creates an embedded_item
that is equal to the original path, i.e. it is not embedded.
Before this change, the variable PROTOBUF_LIBRARIES might get redundant
value for debug and optimized configurations, e.g.
`optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so`.
Some projects may want to use the detailed mangling information
directly instead of using the FortranCInterface_HEADER function.
We already provide variables encoding the mangling information,
so just document them as available.
This commit introduces two new options to CTestCoverageCollectGCOV.
When GLOB is set we recursively search in the source & binary
directories for .gcda files. Otherwise the default behavior is to
parse TargetDirectories.txt for a list of locations to search.
When DELETE is set we remove any .gcda file found after it has
been used to generate the corresponding .gcov file. The .gcov
file is also removed after the result tarball has been created.
Together these two new features help support the use case of
computing coverage across subprojects.
81ecc726 FindCUDA: Added some additional comments about non-existent dependency files.
4b561b4c FindCUDA: Fix for when a non-existent dependency file is found.
Due to #4662 -isystem support was disabled for all GNU Compilers
on Apple platforms. But the change was probably a just work around
for a broken compiler on Tiger (see 10837#c27206). So we tighten
the condition to only kick in for GCC versions earlier than 4.
That should ensure sane behavior for Xcode 3.2 and later.
Previously if a non-existent dependency file is found we set the file to "" and
then do if(NOT IS_DIRECTORY "${file}"). Later we call get_filename_component
on the empty file which returns basically the current build directory.
Having a dependency on the current build directory is really annoying, because
anything that compiles into that directory will change the file stamp and
cause your files to rebuild every time you call make. :(
Since commit v3.5.0-rc1~32^2~1 (ExternalProject: Simplify `cmake
--build` configuration passing, 2016-01-19) we use the `$<CONFIG>`
generator expression to generate the `cmake --build . --config <config>`
value for the default BUILD_COMMAND instead of the CMAKE_CFG_INTDIR
placeholder value provided by multi-config generators. However, some
projects have been abusing the old implementation detail by setting
CMAKE_CFG_INTDIR themselves to get a specific configuration. Those
projects should be updated to set their own BUILD_COMMAND to get
non-default behavior. Meanwhile we can be compatible with their
existing releases by detecting when CMAKE_CFG_INTDIR is not a
generator-provided placeholder and using its value instead.
The dependency flags require recent versions of `iccarm` and `iccavr`.
The multi-rule dependency generated with `--dependencies=m` does not
work well with Ninja, so use `--dependencies=ns` instead.
Imported targets are now the recommended way of dealing with external
library dependencies. Add one for FindPNG and update documentation
accordingly. Also add a test case activated by CMake_TEST_FindPNG.
Check CMAKE_CONFIGURATION_TYPES instead of CMAKE_CFG_INTDIR in order
to recognize multi-config generators. Then use $<CONFIG> to pass
the configuration value.
The original value is saved in `_pkg_config_path_old`. Fix this typo
left by commit v3.1.0-rc1~763^2 (FindPkgConfig: Extend PKG_CONFIG_PATH
using CMake variables, 2014-03-06).
In Modules/Platform/WindowsPaths.cmake our previously recorded
environment variable combinations no longer seem to be correct. For
example, a 64-bit cmake binary may see ProgramW6432 in the environment
and end up not considering the "ProgramFiles(x86)" variable. Instead
check for all possible environment variables in the preferred order and
then remove duplicates.
Reported-by: Shawn Waldon <shawn.waldon@kitware.com>
Add `VERBATIM` to all `add_custom_command` calls so that CMake will
escape arguments properly even when special characters such as "()" are
present.
Suggested-by: Nils Gladitz <nilsgladitz@gmail.com>
Most packages install their .pc files into PREFIX/lib/pkgconfig, but
some put them into PREFIX/share/pkgconfig. Either is valid, and
pkg-config itself looks in both for the /usr and /usr/local prefixes.
This fixes an issue where some packages (yajl, for example) are not
found if they are installed into a non-standard prefix and
CMAKE_PREFIX_PATH is used to locate them.
This improvement to the FindDCMTK module improves compatibility with recent
DCMTK, which provides a DCMTKConfig.cmake file. See the module comments for a
compatibility matrix.
It also provides DCMTK_INCLUDE_DIRS.
Ported from CommonTK (commontk.org).
This was added by commit v2.8.0~2292 (... Set variable
wxWidgets_INCLUDE_DIRS_NO_SYSTEM on the Mac ..., 2008-04-16) and updated
by commit v2.8.9~183^2 (FindwxWidgets: Do not use -isystem on OpenBSD,
2012-05-14). Since the underlying cause was never investigated fully we
do not know the conditions under which -isystem breaks wxWidgets, but
suppressing -isystem is problematic for users that do not want to see
warnings in wxWidgets headers. Simply drop the special case for now so
we can see whether anyone hits the problem again, at which point it can
be investigated in more detail.
Reported-by: Simon Wells <swel024@gmail.com>
Drop the 'UNIX' condition on Clang compiler features. This enables
use of compile features with MinGW Clang, though additional work may
be needed for clang-cl.
The if(STREQUAL) expressions do not support globbing expressions.
Use regular experssions with MATCHES instead.
Reported-by: Yahui Wang <youngqv@foxmail.com>
VS expects the platform to be just `Itanium`, so drop the incorrect
special case mapping it to `ia64`. This platform name has been wrong
since the logic was added by commit v2.8.10~148^2~8 (VS: Detect the
compiler id and tool location, 2012-08-16).
24cdb9df CMake: Mimic NSIS options dialog in WiX installer
de77d4a7 CPackWIX: Allow multiple patch files and diagnose if any are missing
38d723b3 CPackWIX: Allow patching of shortcut components
When parsing implicit include dirs, link dirs, and link libs, all
arguments are resolved to absolute paths instead of relative paths.
This is correct for link and include directories but link libraries
should only include the library name, not it's path.
The `otool` command may return multiple RPATH entires, so call
`gp_append_unique` for each one. Otherwise we may try to ask
`install_name_tool` to deal with the same entry twice.
Implement a native `cmake_parse_arguments` command that is fully
compatible with the documented behaviour of the previous implementation.
Leave the CMakeParseArguments module empty but existing for
compatibility.
CPACK_WIX_PATCH_FILE now accepts a list of patch files.
An error will now be produced if any of the patch files is missing.
Previously this would be silently ignored.
CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even
though AGL is not GLU. AGL is simply the GL component for the
deprecated Carbon framework. GLU is provided by OpenGL.framework.
A side effect of the old behavior was that if AGL was not found
(it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND
would be incorrectly set to "NO".
All other modules use their module name (e.g. XxX for FindXxX.cmake) in
find_package_handle_standard_args. Protobuf used all-caps, which triggers
a bug when we try to find Protobuf with the CMakeFindDependencyMacro.cmake
macro, which only checks for the mixed-case _FOUND.
The CMAKE_SHARED_LIBRARY_LINK_<LANG>_FLAGS setting has always been meant
for flags needed to export symbols from executables for use by shared
library plugins. Since commit v3.4.0-rc1~58^2~1 (CMP0065: Restrict the
use of CMAKE_SHARED_LIBRARY_LINK_<LANG>_FLAGS, 2015-08-24) this is made
explicit by using the flags only for executables with ENABLE_EXPORTS,
guarded by CMP0065 for compatibility.
On some platforms we were accidentally using this setting to pass other
flags to the linker:
* AIX: -bnoipath, -brtl
* HP-UX: +s, +nodefaultrpath
These flags are incorrectly dropped when CMP0065 is set to NEW. Fix
this by moving the flags to more appropriate places for linking
executables.
This patch solves the problem of installing both: Device and Simulator
libraries on iOS. Before only one of them was installed.
If the IOS_INSTALL_COMBINED property is set on a target, a
special install hook will be activated which builds the corresponding
target and combines both at the install location.
The original patch was contributed by Ruslan Baratov, and polished by
Gregor Jasny.
Some OpenAL implementations on Windows provide both Win32 and Win64
binaries. Search the location of the matching architecture.
Author: George "Zogzer@GitHub" <insertlogic@gmail.com>
This is an extensive refactoring of the Cray compiler wrapper usage.
Using the new compiler wrapper checks, the CrayPrgEnv info files have
been moved from Platform/ to Compiler/. The adjusted naming convention
allows the compiler-wrapper information files to be loaded for both the
CrayLinuxEnvironment platform when cross-compiling and the Linux
platform if building natively on the Cray compute nodes. It also
creates a separation of common arguments for compiler id and language
information used to perform the appropriate introspection of implicit
arguments and libraries used by the compiler wrappers based on the
loaded module environment.
- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
target
Also:
- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
TIFF_INCLUDE_DIRS
7a327727 Embarcadero: Fix erroneous interpretation of __CODEGEARC_VERSION__.
25211d75 Compiler ID: Compiler versions must be a valid, numeric version string.
060442c2 Embarcadero: Check code using CMAKE_CXX_COMPILER_ID and CMAKE_C_COMPILER_ID.
f3b3219c Embarcadero/Watcom: Properly skip VSResource test for other generators.
ddbda722 Embarcadero: Fix bug where duplicate Ninja job pools would be created.
As per the following link:
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Example_of_CODEGEARC_VERSION_Macro
The major/minor versions must be decoded as a hex string, while the patch
version must be decoded as a normal decimal string.
As an example, C++ Builder XE 8.1's bcc32.exe sets this macro to 0x070189C9.
The file version of bcc32.exe is 7.1.5570.35273. Therefore, the correct
interpretation to COMPILER_VERSION would be 7.1.35273.
The CMAKE_CXX_COMPILER_ID and CMAKE_C_COMPILER_ID variables are set to
"Borland" for older versions of the compiler. Newer CodeGear/Embarcadero
compilers will have those variables set to "Embarcadero". Search for lines of
code referencing both the variable name and Borland to be sure that they also
refer to Embarcadero.
Fix typos introduced by commit v3.4.0-rc1~257^2~2 (FindJava: Add support
for idlj and jarsigner tools, 2015-07-31) to correctly report when these
components are found.
The function _Boost_MISSING_DEPENDENCIES will look at the
user-supplied component list, check the dependency
information for each component using
_Boost_COMPONENT_DEPENDENCIES, and will add any missing
dependencies to the component list. This ensures that
all required components will be searched for.
The function _Boost_COMPONENT_DEPENDENCIES is used to query the
library dependencies for a given component for a given version of
Boost. This covers Boost releases from 1.33 to 1.59, using the
information generated by Utilities/Scripts/BoostScanDeps.cmake.
When both CPACK_DMG_SLA_DIR and CPACK_RESOURCE_FILE_LICENSE are defined,
use the license file for all languages instead of looking for a license
file for each language. Also expand the documentation on the SLA
variables.
In commit v3.4.0-rc1~18^2 (Disable shared library support when compiler
links statically, 2015-09-30) we tried to detect when the compiler is
not capable of linking shared libraries (possibly due to flags in use).
However, the approach is not robust against flags like `-nostdlib`.
Revert it for now pending another solution to the original problem.
Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version. This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.
When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur. Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced. However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.
Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler. In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.
In commit v3.4.0-rc1~71^2 (Project: Determine default language dialect
for the compiler, 2015-09-15) we added an "INFO:..." string to the
compiler id detection binary. The value can be optimized out of the
compiler id binary unless we force it to be included by making the
program behavior depend on it at runtime. Add references to the value
as we do for the other info strings already.
Gentoo-Issue: https://bugs.gentoo.org/show_bug.cgi?id=565744
Our CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES setting is no longer needed
because CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES is now populated with the
actual implicit link directories for the current toolchain. The old
values we hard-coded in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES are not
relevant to modern toolchains, so simply drop them.
Co-Author: Shawn Walker-Salas <shawn.walker@oracle.com>
Brad King
Nils Gladitz
Erik Zenker
Sergiu Deitsch
Paweł Stankowski
Geoff Viola
Ben Boeckel
J M Dieterich
Sean McBride
Andreas Schuh
Zak Eckert
Ruslan Baratov
Roger Leigh
Han Sangjin
Mariusz Pluciński
O. Libre
Jean-Christophe Fillion-Robin
Antonio Perez Barrero
Philippe Proulx
Clinton Stimpson
Marc Chevrier
Alex Neundorf
Florian Apolloner and John Knottenbelt
Wayne Stambaugh
Domen Vrankar
Christian Askeland
Zack Galbreath
James Bigler
Gregor Jasny
Juhani Simola
Christoph Grüninger
Sergei Nikulov
Sam Thursfield
Roger Leigh
André Klitzing
Rob Gowin
Adam Rankin
Matt McCormick
Chuck Atkins
Emilie Harquel
Matthias Maennich
David Gobbi
Sebastian Schuberth
Chris Pavlina
Markus Rickert
James Johnston
Simon Levermann
Alexander Szakaly
Roger Leigh
April Chin