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>
4bca9401 Improve appearance of CMake .dmg package on OS X
c4b9ee18 CPack/DragNDrop: Update documentation to include new variables
167a4655 CPack/DragNDrop: Optionally run an AppleScript when making a package
9c1dfbfd CPack/DragNDrop: Place the background image file in a hidden folder
47302038 CPack/DragNDrop: Use source file extension for background image
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.
Brad King
Alexander Szakaly
Roger Leigh
Chuck Atkins
April Chin
Robert Maynard
Domen Vrankar
Markus Rickert
Daniele E. Domenichelli
Simon Levermann
Raffi Enficiaud
Rolf Eike Beer
Joakim Andersson
Benjamin Chrétien
Marc Chevrier
Chris Davies