(I accidentially removed ExternalProject.cmake from git by doing
mv ExternalProject.cmake ExternalProject.cmake.save
git checkout master
which I hoped would basically do a revert as it does with svn and cvs, but it
deleted the file from git)
Alex
Detect the runtime linker's search path and add to the compile time
linker's search path. This is needed because OpenBSD's static linker
does not search for shared library dependencies in the same places as
the runtime linker.
Teach compiler identification to support values such as
export CC='gcc -g -O2'
by separating the arguments on spaces. We already do this for the
values of CFLAGS, CXXFLAGS, and FFLAGS.
This allows the user not to link to the common libraries,
which are regularly required. The user must specify all
libraries that he does want to link in the find_package
line (png tiff jpeg zlib regex expat).
--HG--
extra : rebase_source : df29f96c957600629a34a1c5fafb8b3d6f274e22
Allow the user to set the CMake variable CTEST_COST_DATA_FILE, which will be used to store the cost data from test runs. If not set, defaults to the original location in the build tree Testing/Temporary dir.
Commit "Modernize GNU compiler info on Windows" (2009-12-02) reorganized
GNU flags on Windows but let -fPIC slip through for compilation of
objects in shared libraries. While this flag is valid on most GNU
compiler platforms we need to suppress it in Windows-GNU.cmake just as
we already do in CYGWIN-GNU.cmake.
This modifies the behavior of PYTHON_WRITE_MODULES_HEADER, should be backwards
compatible. Also marked a couple of the variables generated by adding Python
modules as advanced.
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.
