CMake does not enable Fortran for its own build, but it needs to find a
Fortran compiler to know if it is possible to enable Fortran tests.
Previously we searched for a hard-coded list of Fortran compilers which
was duplicated from the CMakeDetermineFortranCompiler.cmake module. We
now run CMake on a small test project that enables the Fortran language
and reports the compiler it found. This represents a more realistic
check of whether the Fortran tests will be able to find a compiler.
Previously this module gave only very brief documentation. We extend
the module's documentation to describe CTestConfig.cmake, interaction
with dashboard scripts, and the CTEST_USE_LAUNCHERS option.
We remove the shared library compile/link flags "-fPIC" and "-shared"
because they are not provided by all compilers on Linux. This allows us
to drop code from the Linux-XL-*.cmake files that erases the bad flags.
All other supported compilers already provide their correct flags for
Linux in their own platform information files.
We factor flags from Platform/Linux-PGI-Fortran.cmake into language
independent helper modules
Compiler/PGI.cmake
Platform/Linux-PGI.cmake
and invoke the macros from
Compiler/PGI-<lang>.cmake
Platform/Linux-PGI-<lang>.cmake
This enables general support for the PGI compilers.
The commit "Split GNU compiler information files" intended to move GNU
flags from the platform-wide Platform/SunOS.cmake module into
Platform/SunOS-GNU-<lang>.cmake
using a helper module Platform/SunOS-GNU.cmake to consolidate flags.
However, it accidentally put Fortran flags in the C language module and
left out the Fortran module altogether. This fixes those mistakes.
Several platform-wide linker flag variables are defined in
Modules/Platform/<os>.cmake files for C and then copied by the
Modules/CMake<lang>Information.cmake file for each language.
We now use this approach for the variables
CMAKE_EXE_EXPORTS_${lang}_FLAG
CMAKE_SHARED_LIBRARY_SONAME_${lang}_FLAG
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS
to avoid duplication for multiple languages in each platform file.
The commit "Split GNU compiler information files" broke the settings of
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS
CMAKE_SHARED_MODULE_CREATE_${lang}_FLAGS
and started using just "-shared" for them. This worked when tested on newer
Mac machines, but older ones really need "-dynamiclib" and "-bundle" (which are
the documented flags anyway).
This moves GNU compiler info on Windows into new-style modules
Platform/Windows-GNU-<lang>.cmake
using language-independent helper module
Platform/Windows-GNU.cmake
to define macros consolidating the information.
This moves GNU compiler flags into new-style modules
Compiler/GNU-<lang>.cmake
Platform/<os>-GNU-<lang>.cmake
We use language-independent helper modules
Compiler/GNU.cmake
Platform/<os>-GNU.cmake
to define macros consolidating the information.
The CMakeBackwardCompatibilityC module provides some try-compile results
that were automatically provided by CMake 1.4. When performing the
checks for OS X universal binaries we just pick one architecture to get
through the checks without error. Since CMake 1.4 did not support any
universal binaries, projects that want them should not depend on this
compatibility module anyway.
This is a GNU-specific option that should not be specified for all
compilers on Linux. It tells the GNU compiler to pass -export-dynamic
to the linker to export symbols from executables for use by plugins.
Since we provide the ENABLE_EXPORTS target property to do the same thing
in a cross-platform way, there is no need to pass -rdynamic always.
Since the option is not useful for GNU tools and breaks other tools on
Linux we simply remove it from CMAKE_SHARED_LIBRARY_LINK_<lang>_FLAGS.
This also allows us to stop setting the variable in other Linux compiler
files just to erase the bad flag.
See issue #9985.
The Watcom tools do their own command-line parsing and do not accept
double-quotes. Instead we single-quote the target output name when
invoking wlink and other Watcom tools. This fixes support for spaces in
the target output directory path when it is not under the build tree.
-use find_package(PkgConfig) instead of include(UsePkgConfig)
-remove the "if already cached make silent" logic, this is already handled by find_package_handle_standard_args()
-remove the if(WIN32) around pkg-config, it shouldn't be necessary
Alex
We pass CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, and CMAKE_Fortran_FLAGS through
try_compile() for the FortranCInterface Detect and Verify projects.
This honors user-specified compiler flags for each language, thus
supporting flags that affect the Fortran mangling.
The FortranCInterface module should execute with CMake 2.8.0 behavior
even if policies are set differently by the including project. In
particular, it makes use of empty list elements and therefore expects
NEW behavior of CMP0007.
Qt4Macros.cmake: all the "public" macros of FindQt4.cmake
Qt4ConfigDependentSettings.cmake: the code for detecting the
Qt-configuration dependent additional libraries, e.g. when linking statically.
There should be no functional changes in this patch.
The patch reduces the length of FindQt4.cmake from 1700 lines to around 1000
lines, which is still long enough, but this should make the file a easier to
handle (and it is similar to what we do in KDE with FindKDE4Internal.cmake
and KDE4Macros.cmake)
Ok by Clinton.
Alex
This should not change the result (since both should be in the same
directory), but seems a bit more logical and is also in sync with what is done in the KDE version.
Alex
-the mark_as_advanced() calls for the variables coming from qmake are now in
the corresponding section, and not in the section where the include dirs are
foudn
Alex
Brad King
Alexander Neundorf
Mathieu Malaterre
David Cole
James Bigler
Eric Noulard
Bill Hoffman
Clinton Stimpson
Will Dicharry
Dave Partyka