PathScale Fortran mangles module symbols as "MY_SUB.in.MY_MODULE" and
also requires "my_module_" when the module is imported. We cannot
provide the symbol with ".in." mangling so we should not provide
"my_module_" because it would duplicate the one in the Fortran-provided
object file.
Commit "FortranCInterface: Fix PathScale detection" (2010-01-22) already
made the same fix for the non-underscore module case.
In the CTest module we previously warned if the source directory did not
contain known version control directories. The message was:
"CTest cannot determine repository type. Please set UPDATE_TYPE
to 'cvs' or 'svn'. CTest update will not work."
This was confusing when building sources from a tarball. Furthermore,
we now support many more version control tools. This feature is now
mature enough that the warning causes confusion more than it provides
real help. We simply remove it.
The compiler documents symbols _DF_VERSION_ and _VF_VERSION_ but they do
not seem to be available to the preprocessor. Instead we add a vendor
query table entry for Compaq. Running "f90 -what" produces
Compaq Visual Fortran Optimizing Compiler Version ...
This clearly identifies the compiler.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" and also
requires "mymodule_" when the module is imported. We cannot provide the
symbol with ".in." mangling so we should not provide "mymodule_" because
it would duplicate the one in the Fortran-provided object file.
In commit "use export all symbols on cygwin" (2003-01-21) we started
passing -Wl,--export-all-symbols when linking shared libraries. Now
cygwin exports all symbols automatically if no symbols are explicitly
exported. When symbols are explicitly exported we want to honor that
narrow interface. Therefore this flag should not be passed.
Change based on patch from issue #10122.
The variable should contain the name of a library needed to link the
symbol equivalent to dlopen. On Cygwin no special library is needed,
and certainly not "gdi32".
Change based on patch from issue #10122.
After discussing with Brad and Clinton:
-the namespace for the imported targets is now "Qt4::", tested with Makefiles, Visual Studio and XCode projects
-the imported targets are always created
-if QT_USE_IMPORTED_TARGETS is set to TRUE (it defaults to FALSE), the QT_QTFOO_LIBRARY variables are set to point to these imported
targets, otherwise the old behaviour is used.
-on OSX if Qt has been found as framework, disable QT_USE_IMPORTED_TARGETS, since cmake doesn't handle the framework directory as location of the library correctly
Alex
-set the type of the IMPORTED libraries to UNKNOWN, this way also on Windows
only the "LOCATION" property has to be set
-the if() around the SET(QT_${basename}_FOUND 1) was useless (always true)
-the mapping of the configuration types DEBUG and PROFILE did not belong here
Alex
This commit syncs FindQt4.cmake again with KDEs version.
Now for every Qt library an imported target with the name
Qt4ImportedTarget__<LIBNAME> is created.
This way we can now finally handle the release and debug versions of the Qt
libraries correctly.
Also, if a Qt-using project A installs a file with exported targets, these
targets now depend on the imported Qt targets, e.g.
Qt4ImportedTarget__QtCore. The location of QtCore is then resolved at
buildtime of project B, which uses the exported targets from project A.
Before this patch the full path to the QtCore on the original build machine
of project A was stored, so this had to match the directory layout on the
build machine for project B.
Alex
While Cygwin supports linking directly to .dll files, the behavior is
now discouraged. All Cygwin packages now provide import libraries of
the form lib*.dll.a and CMake has built the import libraries for years.
We believe it is now safe to stop explicitly searching for .dll files
because their import libraries will always be available when the
corresponding header files are available. Users can always set
find_library cache entries to point at a .dll file by hand if they
really must use one.
Change based on patch from issue #10122.
Commit "Find locally installed software first" made /usr/local the first
prefix searched to be consistent with the Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/
The standard also implies that the root prefix "/" should not have any
package or development files. The "/bin" and "/lib" directories should
have only minimal contents to boot the system. No "/include" ever
exists. This commit re-orders the search path prefix list from
/usr/local
/
/usr
to
/usr/local
/usr
/
to prefer package and development files over low-level system files.
See issue #10136.
On Cygwin /usr/lib == /lib and /usr/bin == /bin. This change also makes
search results report locations as "/usr/..." instead of "/lib/...".
See issue #10122.
We add compiler information files
Compiler/PathScale-<lang>.cmake
to specify PathScale compiler information for C, C++, and Fortran
languages. We use a macro in Compiler/PathScale.cmake to consolidate
the information common to all languages.
The commit "Drop -rdynamic from Linux build rules" removed default use
of the flag on Linux. It was expected to be compatible because any
project using plugins should set ENABLE_EXPORTS on its executables to
export their symbols for use by the plugins in a cross-platform way.
However, it is possible to build without ENABLE_EXPORTS and load plugins
that do not link to any symbols from the executable explicitly. These
plugins may need to see RTTI and other executable symbols needed by the
language implementation. Executables using such plugins were broken by
the change.
If we want to remove the -rdynamic flag in the future we should do so in
a compatible way. At that time we should also remove equivalent flags
on other platforms (like -bexpall on AIX). We will either need a policy
or an explicit API to disable symbol exports on executables.
The primary purpose of the above-mentioned commit was to avoid passing
the -rdynamic flag to compilers on Linux that do not support it. In
this commit we restore the flag but only on GNU and Intel compilers
which are known to support it.
See issue #9985.
Implement Fortran 32/64-bit ABI detection on some platforms. We need to
set CMAKE_SIZEOF_VOID_P correctly in Fortran-only projects so that the
find_library() command knows whether to look for 64-bit binaries. We
also detect ELF binaries to enable RPATH replacement. See issue #10119.
Now the case that both the release- and the debug-version of a library is
handled first, because otherwise we always ran into this branch, since the
debug-only and the release-only branch also set both variables.
Alex
We modify the signature of _HDF5_parse_compile_line to pass the command
line variable name rather than the command line itself. Otherwise the
CMake language MACRO implementation tries to parse the command line as
CMake syntax, which does not like backslashes.
We re-implement this module to support architecture-dependent type
sizes. In the mixed-size case we generate C preprocessor code to select
the detected type size for each architecture.
before this patch -F<framework> dir had to be added manually in some way
when using Qt4 installed as framework and when using FindQt4.cmake directly,
i.e. without UseQt4.cmake. With this patch the framework dir is
automatically added to QT_INCLUDE_DIR when Qt is installed as a framework.
Ok by Clinton, tested already in KDE by Mike Arthur.
Alex
The commit "FortranCInterface: Honor language flags in checks" taught
the FortranCInterface module to pass C and Fortran flags into its
detection and verification checks. We improve on the change to allow
the '=' character in the language flags. This requires passing the
cache entry type with the -D options.
CMake 2.8 was released with the FindHDF5 module setting HDF5_INCLUDE_DIR rather
than the correct plural HDF5_INCLUDE_DIRS. Since this went into a release, it is
now necessary to set the singular for backwards compatibility.
Replace them with CPACK_PACKAGE_NAME. The registry keys involved in this commit are used by Windows to track things in the Add/Remove programs portion of the Control Panel. With '\' characters in the keyname, the calls do not do what they are intended to do and the installed program never shows up in the control panel view. (Details noted in the issue itself.) Thanks to 'killerfox' for the patch.
Default to "" for CMAKE_OSX_DEPLOYMENT_TARGET if CMAKE_OSX_SYSROOT is set. Also, add new error message to detect the case where there is a deployment target, but no SDK has been set. Fix args to STRING REGEX call so that it works even if _sdk_path variable is empty inside sanity check function.
When there is no shared object to link to a second call to find library is
necessary to find the static Python library. Fixes an issue raised on the CMake
mailing list, and it should be included in the next CMake patch release.
We add the macro CMAKE_FORCE_Fortran_COMPILER to the cross-compiling
helper module CMakeForceCompiler.cmake so that toolchain files can force
a Fortran compiler as well as C and C++ compilers. See issue #10032.
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
Some compilers use implicit link options of the form
-lcrt*.o
-lgcc*
-lSystem (on Mac)
-lSystemStubs (on Mac)
that provide system-wide symbols not specific to any language.
These need not be listed explicitly for mixed-language linking.
We teach CMake to remove the above items from the implicit library list
of each language. This change makes it possible to mix GNU compiler
versions in some cases.
BUILD_SHARED_LIBS is now only recognized when calling CUDA_ADD_LIBRARY. If you want the CMAKE_SHARED_LIBRARY_C/CXX_FLAGS to be used, pass SHARED as an argument. This prevents -fPIC from being used on objects destined for executables by default.
We replace "/MD" with ifort-specific flags as follows:
/MD -> /threads /libs:dll
/MDd -> /threads /libs:dll /dbglibs
We also enable the "/MD" equivalent for all Fortran configurations.
Previously multithreaded dll runtimes were used for release builds and
threaded static runtimes for debug builds. For mixed Fortran C/C++
projects, this led to link warnings for Debug but not for Release.
See issue #8744.
We add Intel and MinGW Fortran linker options to create the import
library portion of a DLL. This allows other binaries to link to a
Fortran DLL.
We also update the Fortran test to use a .def file to specify exports
since there is no __declspec(dllexport) markup syntax in Fortran.
This commit teaches CMake about the g95 compiler from
http://www.g95.org
We use 'G95' as the compiler id string, and add some basic flags.
See issue #9241.
although #9621 did not happen anymore with cmake 2.8.0, probably because
GET_PROPERTY(... GLOBAL ...) now makes the result variable empty instead of
simply not touching it, using FUNCTION() instead of MACRO() makes sure that
the _EnabledFeatures variables is always empty before the GET_PROPERTY()
call (and does not still have the old value from the previous call)
Alex
1. Add STATUS output "Could NOT find Boost" if boost is not found
which brings FindBoost closer in behavior to most CMake find modules.
2. Add an option: Boost_DETAILED_FAILURE_MSG to output
Boost_ERROR_REASON on a non-REQUIRED find if this
is desired by the developer. This is done because the error messages
are rather long and software with optional Boost dependencies might
not like them showing up by default, especially since this wasn't done
before.
3. Add mention of Boost_ADDITIONAL_VERSIONS close to top
of file since this seems to be the most common problem brought
up on the mailing list (maybe people will notice it there)
4. Added additional check for intel compiler which probably isn't
necessary but ultimately should be cleaner if CMAKE_CXX_COMPILER_ID
sticks around.
5. Added my name to the Copyright list
This commit re-writes Borland compiler build rules. We split the rules
into modern <os>-<id>-<lang> information modules but share a common
macro between languages to avoid duplication.
We also address a bug in the previous rules that would build some target
types against the static Borland runtime and others against the shared
Borland runtime in one build tree. Now we always use the shared runtime
as is the default in the rules for MS tools.
This teaches the FindVTK module to use the Config mode of find_package()
to search for VTKConfig in the common case. The old search method based
on find_path() and UseVTK is now used only to search for VTK 4.0.
This approach avoids the need to update the module for each new VTK
version because find_package(VTK) automatically searches "lib/vtk*". It
also addresses issue #9105 since find_package searches lib64 paths too.
The regex used by CMAKE_PARSE_IMPLICIT_LINK_INFO to detect link lines
should not match lines that happen to have ".../ld.../..." in them. A
linker name should match only as the last component of a path.
See issue #9666.
This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log
the regex it uses to detect the linker invocation line. The regex is
computed from the CMAKE_LINKER if it is found, so it might change. A
strange value might match the wrong line and cause implicit link info
extraction to fail.
See issue #9666.
This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log
its actions. We store the log in CMakeFiles/CMakeOutput.log at the top
of the project build tree. This will make diagnosis of implicit link
information parsing problems easier.
The commit "fix for bug 4772" added a work-around to CMakeCInformation
for platform config files that put compiler information in the system
file (like SunOS flags for GCC). This commit adds the same work-around
for CXX and Fortran. It is necessary to support enabling these
languages separately from C in other subdirectories.
The commit "Avoid (Unix|Windows)Paths.cmake multiple include" added
include blockers that prevent the files from multiple inclusion, so it
is safe to include the system information files from every language.
See issue #4772 and issue #9656.
Block multiple inclusion because "Modules/CMakeCInformation.cmake"
includes "Platform/${CMAKE_SYSTEM_NAME}" even though the generic
module "CMakeSystemSpecificInformation.cmake" already included it.
The extra inclusion is a work-around to address issue #4772 without
intrusive platform file changes. Once those changes are made the
work-around and these include blockers can be removed. See issue #9656.
This commit re-orders the search path prefix list from
/
/usr
/usr/local
to
/usr/local
/
/usr
so that locally-installed software is preferred.
This makes the search consistent with the Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/
See issue #9657.
Most problems are fixed (or rather worked-around) by making long '====='
separators pre-formatted (i.e. prefixed with two spaces). In order to
preserve visual view, the code examples themselves are prefixed with 3
spaces.
This commit fixes the following man warnings:
$ cmake --help-man - | LANG=C MANWIDTH=80 man --warnings -l - > /dev/null
<standard input>:6024: warning [p 105, 1.7i]: can't break line
<standard input>:6027: warning [p 105, 2.7i]: cannot adjust line
<standard input>:6027: warning [p 105, 2.8i]: can't break line
<standard input>:7142: warning [p 117, 7.8i]: can't break line
<standard input>:7171: warning [p 117, 11.8i]: can't break line
<standard input>:8878: warning [p 136, 9.0i]: can't break line
<standard input>:8887: warning [p 136, 11.5i]: cannot adjust line
<standard input>:8887: warning [p 136, 11.7i]: can't break line
<standard input>:8904: warning [p 136, 14.2i]: can't break line
Patch from Modestas Vainius. See issue #9659.
GNU/kFreeBSD = FreeBSD kernel + userspace with glibc. Linux.cmake
doesn't contain anything too OS specific, so we can forward to it.
Here are outputs of /bin/uname on author's machine:
uname -p ==> i386
uname -o ==> GNU/kFreeBSD
uname -s ==> GNU/kFreeBSD
uname -r ==> 5.4-1-686
Patch from Modestas Vainius. See issue #9659.
On Debian moc and uic from Qt3 have '-qt3' suffixes. The latter names
might come from Qt4, so prefer the version-specific names.
Patch from Modestas Vainius. See issue #9659.
This module was contributed under a BSD-like license. We added CMake's
OSI-approved BSD License on top of it. With the author's permission,
this commit removes the old license text and puts the author's copyright
notice in the block referring to the new license.
-remove the parentheses in the if() conditions, they don't change the
result, and without them these lines are identical to the ones in
FindQt4.cmake from KDE
-mention which qmake was used for finding Qt
Alex
This commit creates target and directory properties to enable the Intel
interprocedural optimization support on Linux. Enabling it adds the
compiler option '-ipo' and uses 'xiar' to create archives.
See issue #9615.
Other minor changes:
* Enhanced documentation & added examples
* _INCLUDE_DIRS and _LIBRARIES was being set regardless of _FOUND
* Fixed status message to include library rather than include dir
* Improved detection of MSVC compiled libraries
* Added a variable (GTEST_BOTH_LIBRARIES) for libgtest + libgtest_main
This commit adds some default initial C flags for the XL compiler. The
most important is "-qhalt=e" which causes the compiler to error-out on
non-severe error messages. This is necessary to get try-compiles to
fail when bad arguments are passed to a function.
This moves platform-independent XL compiler flags into separate
"Compiler/XL-<lang>.cmake" modules. Platform-specific flags go in
"Platform/<os>-XL-<lang>.cmake" modules.
Since Haiku does not have /usr (and therefore /usr/local), this commit
changes the default install prefix to the equivalent directory of
/boot/common.
See issue #9607.
Cutil was never intented to be used outside of the SDK. The removal of this
code is in support of this. The CUDA_SDK_ROOT_DIR will continue to be
supported, in case users wish to use this to find files in the SDK. There are
also two examples of how to use CUDA_SDK_ROOT_DIR to find header files and
libraries if users so wish.
The CUDA_PROPAGATE_HOST_FLAGS was incorrect in that it prevented the CUDA_NVCC_FLAGS_CONFIG variable from getting filled.
Also, added a search path for the CUDA SDK install on Macs.
This adds copyright/license notification blocks CMake's non-find
modules. Most of the modules had no notices at all. Some had notices
referring to the BSD license already. This commit normalizes existing
notices and adds missing notices.
This adds copyright/license notification blocks CMake's find-modules.
Many of the modules had no notices at all. Some had notices referring
to the BSD license already. This commit normalizes existing notices and
adds missing notices.
- Finished updating and formatting documentation.
- Added CUDA_PROPAGATE_HOST_FLAGS (Default ON) that can disable the C flag
propagation to the host compiler.
_ Changed the output directory for support files from
${CMAKE_CURRENT_BINARY_DIR} to ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles. This
will hopefully reduce the clutter in the binary directory.
Implicit link information contains architecture-specific libraries and
directories. The link information cannot be explicitly specified safely
when CMAKE_OSX_ARCHITECTURES contains more than one architecture.
As a result, we currently cannot support mixed-language C++/Fortran
targets and OS X universal binaries simultaneously. In order to avoid
conflicts for simple C/C++ cases, we now simply skip detection of
implicit link information in this case.
Previously we checked for this flag by parsing the version number of GCC
out of 'gcc --version', but this is not reliable because the format can
vary greatly. Now we run 'gcc -v --help' and look for '-isysroot' in
the list of options.
We also now store the result on a per-language basis in the per-compiler
info file "CMake<LANG>Compiler.cmake". This is necessary to make it
accessible from try-compile projects so that they generate correctly.
These compilers warn and return 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output. We
also update the regex for GNU on older Macs. See issue #9516.
This compiler warns and returns 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output.
See issue #9516.
These compilers warn and return 0 for unrecognized flags. We fix the
compiler flag check macros by looking for a warning in the output.
See issue #9516.
This teaches the CHECK_C_SOURCE_COMPILES and CHECK_CXX_SOURCE_COMPILES
macros to recognize a FAIL_REGEX option. If they see the regular
expression in the output of the test compilation, the check fails.
This commit improves formatting and style of the documentation for the
general-purpose compiler check macros:
CHECK_C_COMPILER_FLAG
CHECK_C_SOURCE_COMPILES
CHECK_C_SOURCE_RUNS
CHECK_CXX_COMPILER_FLAG
CHECK_CXX_SOURCE_COMPILES
CHECK_CXX_SOURCE_RUNS
This sytle is more consistent with CMake command documentation.
It also looks nicer in the generated documentation text files.
Now gcc is queried also for the builtin definitions, and they are then added
to the .cproject file. This should make the preprocessor highlighting in
eclipse work better (#9272)
Patch mostly from Miguel.
Alex
In Platform/Linux.cmake we add GNU flags as default for the platform
which breaks non-GNU compilers. Later we should refactor these flag
files to put compiler-specific flags only in files loaded for each
compiler. Until then this commit fixes the XL C++ compiler flags on
Linux by erasing the GNU flags. See issue #9469.
-now supports specifying minimum required version
-now supports ruby 1.8 and 1.9
-uses find_package_handle_standard_args() now
-fix #6212 and using a lot of ideas from the file attached there
Alex
When CMAKE_Fortran_COMPILER and ENV{FC} are not defined CMake searches
for an available Fortran compiler. This commit teaches the search code
to look for compiler executables next to the C and C++ compilers if they
are already found. Furthermore, we bias the compiler executable name
preference order based on the vendor of the C and C++ compilers, which
increases the chance of finding a compatible compiler by default.
The CMakeExportBuildSettings and CMakeImportBuildSettings modules used
to export compiler paths and flags from one project and import them into
another. The import process would force the settings on the including
project.
Forcing settings helped long ago when compiler ABIs changed frequently
but is now just a nuisance. We've deemed the behavior harmful so this
commit simply removes it. The modules and macros now error out if
included or called from a project that requires CMake 2.8 or higher.
The commit "Split Intel compiler information files" moved some Linux
specific flags into the platform-independent Intel compiler info files.
This moves them back.
The verification program entry point (main) is defined in a C source
file, so the C compiler should be used to link when only Fortran and C
are involved. The C++ compiler should still be used when the CXX option
is enabled.
This function builds a simple test project using a combination of
Fortran and C (and optionally C++) to verify that the compilers are
compatible. The idea is to help projects report very early to users
that the compilers specified cannot mix languages.
We split the main detection logic into a Detect.cmake support module and
load it only when detection results are not already available. This
allows results computed by the main project to be used in try-compile
projects without recomputing them. The call to try_compile() need only
to pass FortranCInterface_BINARY_DIR through the CMAKE_FLAGS option.
This moves platform-independent SunPro compiler flags into separate
"Compiler/SunPro-<lang>.cmake" modules. Platform-specific flags are
left untouched.
The Borland librarian tool "tlib" requires that the output target name
be quoted if it contains the character '-' (and perhaps a few others).
This commit restores the use of the TARGET_QUOTED rule variable
replacement for this purpose. Otherwise no static library can have a
'-' in its name.
This problem was exposed by the 'Testing' test when it builds the
pcStatic library with the '-dbg' suffix.
IBM rebranded its VisualAge compiler to XL starting at version 8.0. We
use the compiler id "XL" for newer versions and "VisualAge" for older
versions. We now also recognize the "z/OS" compiler, which is distinct
from XL.
The CMAKE_Fortran_DEFINE_FLAG value applies to the IBM Fortran compilers
on all platforms. This moves the setting to the platform-independent
compiler information file.
Formerly, fixup_bundle was useful only on the Mac for making standalone bundle applications that could be drag-n-drop moved to anyplace in the file system. fixup_bundle is not just for the Mac any more. It will now analyze executable files on Windows and Linux, too, and copy necessary non-system dlls to the same folder that the executable is in. This should work with dlls that you build as part of your build and also with 3rd-party dlls as long as you give fixup_bundle the right list of directories to search for those dlls. Many thanks to Clinton Stimpson for his help in ironing out the details involved in making this work.
This is a new FortranCInterface.cmake module to replace the previous
prototype. All module support files lie in a FortranCInterface
directory next to it.
This module uses a new approach to detect Fortran symbol mangling. We
build a single test project which defines symbols in a Fortran library
(one per object-file) and calls them from a Fortran executable. The
executable links to a C library which defines symbols encoding all known
manglings (one per object-file). The C library falls back to the
Fortran library for symbols it cannot provide. Therefore the executable
will always link, but prefers the C-implemented symbols when they match.
These symbols store string literals of the form INFO:symbol[<name>] so
we can parse them out of the executable.
This module also provides a simpler interface. It always detects the
mangling as soon as it is included. A single macro is provided to
generate mangling macros and optionally pre-mangled symbols.
This stores CMAKE_Fortran_COMPILER_SUPPORTS_F90 in the Fortran compiler
information file CMakeFiles/CMakeFortranCompiler.cmake instead of in
CMakeCache.txt. This file makes the result available to try-compile
projects.
The commit "Consider link dependencies for link language" taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
We set the variables to contain "-v", the verbose front-end output
option for PGI compilers. This enables detection of implicit link
libraries and directories for these compilers.
We set the variables to contain "-v", the verbose front-end output
option for Intel compilers. This enables detection of implicit link
libraries and directories for these compilers.
This teaches the implicit link line parsing code to recognize link lines
that do not have a full path to the linker executable. At least one
version of the Intel compiler on Linux invokes the linker as just "ld"
instead of "/usr/bin/ld".
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
This removes the file-wise installation rules for Modules and Templates
and instead installs the whole directories. This approach is much less
error-prone. The old approach was left from before CMake had the
install(DIRECTORY) command.
Xcode adds extra link directories that point at the build tree, so
detection of implicit link directories is not reliable. Since Fortran
is not supported in Xcode we will not need implicit link information yet
anyway.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
This teaches the language configuration modules to load per-compiler
information for each language using the compiler id but no system name.
They look for modules named "Compiler/<id>-<lang>.cmake". Such modules
may specify compiler flags that do not depend on the platform.
Some SGI compilers define _SGI_COMPILER_VERSION in addition to the old
_COMPILER_VERSION preprocessor symbol. It is more distinctive, so we
should check it in case the old one is ever removed.
The SGI preprocessor /usr/lib/cpp produces bad output on this code:
#if 1
A
#elif 1
B
#else
C
#endif
Both 'A' and 'C' appear in the output! We work around the problem by
using '#elif 1' instead of '#else'.
This fixes detection of the SGI Fortran compiler id in -o32 mode.
This teaches the ExternalProject module to check the download URL file
name. If it is not a tarball (.tar, .tgz, .tar.gz) it is an error
because UntarFile does not yet understand other archive formats.
When tarball extraction fails we should still cleanup the temporary
extraction directory. Otherwise the next attempt will create a new
directory and the first one will never be removed.
This teaches Modules/Platform/Linux-SunPro-CXX.cmake the -rpath-link flag. The
SunPro C++ compiler does not have a '-Wl,' option, so we just pass the flag
directly.
This problem was exposed by the ExportImport test now that it links an
executable through the C++ compiler with the -rpath-link flag.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This enhances the Fortran compiler id detection by using a source that
can compile either as free or fixed format. As long as the compiler
knows it should preprocess the source file (.F) the identification can
work. Even free-format compilers may try fixed-format parsing if the
user specifies certain flags, so we must support both.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
This enables the --enable-auto-import linker flag on Cygwin when linking
executables. It works with the old gcc 3.x compiler and is necessary
for the new gcc 4.x compiler. See issue #9071.
Previously CTest would drop dashboard submissions at public.kitware.com
on the PublicDashboard project if there was no configuration. The
server no longer supports forwarding to cdash.org, so there is no point
in this default. Furthermore, there should be no default at all because
it could leak information about proprietary projects that are not
configured correctly.
This creates cmCTestBZR to drive CTest Update handling on bzr-based work
trees. Currently we always update to the head of the remote tracking
branch (bzr pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. Patch from Tom Vercauteren.
See issue #6857.
CMakeSystemSpecificInformation.cmake into a separate file,
CMakeEclipseCDT4.cmake
-if CMAKE_EXTRA_GENERATOR is set, i.e. either CodeBlocks or KDevelop3 or
EclipseCDT4, load a matching cmake script file, which can do things specific
for this generator
- added such files for Eclipse, KDevelop and CodeBlocks, one thing they all
do is they try to find the respective IDE and store it in the
CMAKE_(KDEVELOP3|CODEBLOCKS|ECLIPSE)_EXECUTABLE variable.
This could be used by cmake-gui to open the project it just generated with
the gui (not sure this is possible with eclipse).
Alex
After extracting the tarball in a temporary directory we copy the tree
to the destination directory. The 'cmake -E copy_directory' command
does not preserve file timestamps, so we use file(COPY) instead.
The add_external_project function separates its arguments with ';'
separators, so previously no command line argument could contain one.
When specifying CMAKE_ARGS, some -D argument values may need to contain
a semicolon to form lists in the external project cache.
This adds add_external_project argument LIST_SEPARATOR to specify a list
separator string. The separator is replaced by ';' in arguments to any
command created to drive the external project. For example:
add_external_project(...
LIST_SEPARATOR ::
CMAKE_ARGS -DSOME_LIST:STRING=A::B::C
...)
passes "-DSOME_LIST:STRING=A;B;C" to CMake for the external project.
This fixes the get_configure_command_id function to not mistake
CONFIGURE_COMMAND values that run "cmake -P" or "cmake -E" for a CMake
project configuration. These values just help run scripts.
This creates function 'add_external_project_step' to centralize creation
of external project steps. Users may call it to add custom steps to
external project builds.
The add_external_project function parses its arguments and puts them in
properties of the target it creates. This factors out implementation of
the behavior for use by other functions in the module.
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
This creates global property RULE_PROGRESS which can be set to disbale
per-rule progress reporting. On Windows, progress reports may cause a
noticable delay due to the cost of starting an extra process. This
feature will allow scripted builds to avoid the cost since they do not
need detailed progress anyway. See issue #8726.
its system include directories. These are catched in CMakeSystemSpecificInformation.cmake
(only with the Eclipse generator) and then written by the Eclipse generator
in the Eclipse project file. This way Eclipse can find the standard headers
(#7585)
Not sure CMakeSystemSpecificInformation.cmake is the best place to do this.
Alex
This teaches AddExternalProject to run "$(MAKE)" for build and install
steps of CMake-based external projects when using a Makefile generator.
It allows the external project to participate in a parallel make invoked
on the superproject.
This uses the get_property command to simplify property lookup in the
AddExternalProject module. It distinguishes for build and install
argument properties the cases of unset and set to empty.
This creates variable CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to
specify implicit include directories on a per-language basis. This
replaces the previous platform-wide variable. It is necessary to
avoid explicit specification of -I/usr/include on some compilers
(such as HP aCC) because:
1.) It may break ordering among system include directories defined
internally by the compiler, thus getting wrong system headers.
2.) It tells the compiler to treat the system include directory
as a user include directory, enabling warnings in the headers.
See issue #8598.
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
This defines a new CTest configuration variable CTEST_USE_LAUNCHERS.
When set to true it puts 'ctest --launch' in RULE_LAUNCH_* properties
and enables the CTest configuration option 'UseLaunchers'. Currently
this works only for Makefile generators.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
Some OS X linkers want a 'dylib_' prefix on the -compatiblity_version
and -current_version flags while others do not. This passes the flags
through gcc instead since it never wants the prefix and translates the
flags for the linker correctly.
Brad King
David Cole
Bill Hoffman
Zach Mullen
James Bigler
Alexander Neundorf
Clinton Stimpson
Philip Lowman
Will Dicharry
Marcus Hanwell
Mathieu Malaterre
Eric Noulard
Dave Partyka
Ken Martin
Miguel A. Figueroa-Villanueva
Christopher Harvey