In CMakeTestFortranCompiler we build a test program using a Fortran 90
construct to check whether the compiler supports the language. Some
compilers have options to require explicit variable types. Fix the test
program to use an explicit variable type so it passes under such a
configuration.
Suggested-by: Neil Carlson <neil.n.carlson@gmail.com>
9a76d83 VS12: Find proper MSBuild for VSProjectInSubdir test
4e5cb39 Merge branch 'master' into vs12-generator
78fdbbc FindBoost: Add -vc120 mangling for VS 12
e99d7b1 VS12: Generate flag tables from MSBuild v120 tool files
77ac9b8 VS12: Add Visual Studio 12 generator (#14251)
Copy cmGlobalVisualStudio11Generator to cmGlobalVisualStudio12Generator
and update version numbers accordingly. Add the VS12 enumeration value.
Add module CMakeVS12FindMake to find MSBuild. Look for MSBuild in its
now-dedicated Windows Registry entry. Teach the platform module
Windows-MSVC to set MSVC12 and document the variable. Teach module
InstallRequiredSystemLibraries to look for the VS 12 runtime libraries.
Teach tests CheckCompilerRelatedVariables, Preprocess, VSExternalInclude,
and RunCMake.GeneratorToolset to treat VS 12 as they do VS 10 and 11.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
Leave other flags directly in the Makefile command lines and outside
any special inline response file syntax. Otherwise Borland does
not support flags with quotes in response files.
Refer users to the newer CMAKE_<LANG>_COMPILER_VERSION variables.
Use a more concise summary. Format the documentation to look
better in the "cmake --help-module" output.
When Boost_USE_STATIC_LIBS is ON we may complain that Boost libraries
cannot be found even when shared libraries are present. Update the
error message to tell the user explicitly that we want static libraries.
Suggested-by: Laurence R. McGlashan <laurence.mcglashan@gmail.com>
Document the logic that parses for backward compatibility the old
variables that were used to control add_jar prior to named argument
support. In particular, document that the reason this logic exists is
for backward compatibility, and that new features do not need to add to
it.
This fixes#14210. In 2.8.10 CMakeDetermineCompiler.cmake was
modified (or added), and now the _INIT variable must not
be set to a list anymore, before it worked.
Alex
For clang, this allows passing -target <triple> to the compiler, and
for qcc, -V<arch> using toolchain files containing something like
set(triple arm-linux-gnueabihf)
set(CMAKE_C_COMPILER "/usr/bin/clang")
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER "/usr/bin/clang++")
set(CMAKE_CXX_COMPILER_TARGET ${triple})
or
set(arch gcc_ntoarmv7le)
set(CMAKE_C_COMPILER /opt/qnx650/host/linux/x86/usr/bin/qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER /opt/qnx650/host/linux/x86/usr/bin/QCC)
set(CMAKE_CXX_COMPILER_TARGET ${arch})
Both clang and qcc are inherently cross compiler( driver)s.
As CMAKE_ROOT_FIND_PATH can be a list, a new CMAKE_SYSROOT is
introduced, which is never a list.
The contents of this variable is passed to supporting compilers
as --sysroot. It is also accounted for when processing implicit
link directories reported by the compiler, and when generating
RPATH information.
dc1d025 OS X: Add test for rpaths on Mac.
8576b3f OS X: Add support for @rpath in export files.
00d71bd Xcode: Add rpath support in Xcode generator.
94e7fef OS X: Add RPATH support for Mac.
RPATH support is activated on targets that have the MACOSX_RPATH
property turned on.
For install time, it is also useful to set INSTALL_RPATH to help
find dependent libraries with an @rpath in their install name.
Also adding detection of rpath conflicts when using frameworks.
That will allow things like this:
find_package(Qt4)
qt4_generate_moc(myfile.h moc_myfile.cpp TARGET foo) # Note, foo target doesn't
# exist until below.
add_library(foo ...)
The qt4_generate_moc call would use the INCLUDE_DIRECTORIES from
the foo target using generator expressions. Currently it reads
the INCLUDE_DIRECTORIES directory property, meaning that include_directories()
is required.
Support for the TARGET is also added to qt4_wrap_cpp, but not qt4_automoc,
as that is deprecated in favor of the AUTOMOC target property.
The moc tool reports failure if the Q_INTERFACES macro is used with
an argument which has not appeared with Q_DECLARE_INTERFACE, so that is
the basis of the unit test.
The command line arguments are now always written to a file, which is
passed to moc as the @atfile. This was already the case on Windows, but
now it is used everywhere. The reason for that is that it is not currently
possible to expand the list of includes from a target directly in
a add_custom_command invokation (though that may become possible in the
future). There is not a big disadvantage to using the file anyway on
unix, so having one code path instead of two is also a motivation.
This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.
This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target
property is used as the operand to the -fvisibility= compile option
with GNU compilers and clang.
In commit 5b9149e0 (FindBoost: Overhaul caching and search repeat
behavior, 2012-09-24) we refactored the internal library search to use a
_Boost_FIND_LIBRARY macro to wrap around find_library calls. However,
CMake macros re-process escape sequences when evaluating calls inside
the macro after substituting placeholders (a historical bug). In order
to avoid escape sequences, convert backslashes to forward slashes before
passing arguments to the _Boost_FIND_LIBRARY macro.
The line
set( ${basename}_LIBRARY )
removes the normal variable, but if the corresponding cached variable is
present then line
list( APPEND ${basename}_LIBRARY optimized "${_libname}" )
uses that and fails. Replace the original line with
set( ${basename}_LIBRARY "" )
to set the normal variable to empty instead of unsetting it.
In Qt 5.1, Qt5::Core has a INTERFACE_QT_MAJOR_VERSION property
of '5', and since CMake 2.8.11, Qt4::QtCore has an
INTERFACE_QT_MAJOR_VERSION of '4'. This was introduced in
commit 4aa10cd6 (FindQt4: Set the INTERFACE_QT_MAJOR_VERSION for
Qt4::QtCore, 2013-03-16), to produce an error if Qt 4 and Qt 5
are erroneously used by the same target. This can also be used
however to determine the Qt major version, and therefore the
particular moc executable to use during automoc steps. This means
that targets in a single buildsystem can use a selection of Qt 4
and Qt 5, and still take advantage of the CMAKE_AUTOMOC feature
without conflicting.
The ExternalData_LINK_CONTENT option tells ExternalData to convert real
data files it finds into content links and to "stage" the original
content in a ".ExternalData_<algo>_<hash>" file. However, after a data
object has been staged it is possible that a user-provided pattern in
the "REGEX:" option will later match the staged object file. We must
not process staged object files even when a user pattern matches them.
Fix the implementation to not match a staged object file as a normal
data file for conversion. Extend the RunCMake.ExternalData test to
cover this case.
Modify FindProtobuf.cmake to find the pthread library on UNIX platforms,
and to add the same to PROTOBUF_LIBRARIES, as this is a link dependency
of libraries using the protobuf headers.
The variables in this module are used to configure a header file
with defines whose name depends on the name of the target.
As valid names of targets may be invalid for use as defines, convert
the names of the defines used to C identifiers first. This is already
done in C++ code for the DEFINE_SYMBOL property.
This is not as simple as ensuring that the BASE_NAME is a C identifier,
because most of the define names are configurable, and because use of
a BASE_NAME which is not a C identifier, such as 4square can become a
C identifier by specifying a prefix in the generate_export_header
macro.
The significant issue with MODULEs is that on Windows, the exported
symbols must be dllexported and they are not imported.
In other export macro implementations this is done by defining an
export macro outside of any ifdef which depends on definitions set
on the command line. However, with cmake we already expect the
DEFINE_SYMBOL to be defined, so the regular EXPORT macro can be
used by such plugins.
Teach CMakeParseImplicitLinkInfo to convert the CMAKE_LINKER file name
to a regular expression that matches only the original name. Escape
special characters like '+' so they are not treated as regex syntax.
Extend the ImplicitLinkInfoTest to test handling of a CMAKE_LINKER value
with many special characters.
d118b8b Add IAR to the CMakeDetectC(XX)CompilerID.c(pp).in
d33f406 Add regexps for the IAR toolchain to the vendor list.
22fb73a Add support files for C, C++ and ASM for the IAR toolchain.
f055c99 CPackRPM add /usr/lib64 to the list of builtin to-be-excluded path
bac5772 CPackRPM add mechanism to remove path from generated list of file in RPM spec.
Initialize the CMAKE_CONFIGURATION_TYPES cache entry early during
EnableLanguage like the Xcode generator does. Avoid depending on
the MSVC compiler information module to do it. Otherwise code like
project(MyProj NONE)
sets CMAKE_CONFIGURATION_TYPES late (in GenerateConfigurations), and
to only "Debug" and "Release" instead of the standard set of 4.
Reported-by: Paul Smith <paul@mad-scientist.net>
Since Java is a portable language, if you want to use Java when
cross-compiling, UseJava uses the JVM installed on the host. So in this
case, we must use set CMAKE_JAVA_INCLUDE_FLAG_SEP for the current host.
With
SVN_USERNAME ""
SVN_PASSWORD ""
in an ExternalProject_Add() call, the blank username and password
will be passed to the svn checkout/update step commands.
Without this, when CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL is set,
the installer tries to uninstall the old version from the default
installation path for the new version, rather than using the path from
the registry where the old version is installed.
Commit dac78148 (...makes the mingw cross compiler work out of the
box..., 2007-08-02) added to CMAKE_SYSTEM_PROGRAM_PATH and
CMAKE_SYSTEM_LIBRARY_PATH paths like "/bin" and "/lib" with no Windows
drive letter so that cross-compiling to Windows from Linux would search
these paths under CMAKE_FIND_ROOT_PATH. Later commit 2a782880 (...use
CMAKE_SYSTEM_PREFIX_PATH when possible, 2008-01-16) generalized this
approach by instead adding "/" to CMAKE_SYSTEM_PREFIX_PATH.
Both commits assumed that the paths would never match anything on
Windows hosts without a drive letter. However, Windows evaluates these
paths relative to the current working drive letter so find_* commands
may report paths like "/lib/..." when paths like "c:/lib/..." exist on
what happens to be current drive. Such drive-less paths are not
reliable when the working drive changes, so we should not use them.
Fix WindowsPaths.cmake to add '/' to CMAKE_SYSTEM_PREFIX_PATH only when
cross-compiling to Windows from a non-Windows host. This will avoid
searching and finding local paths without a drive letter on Windows.
Set the locale to C while running the compiler for these checks because
we match the resulting warning messages in English only.
Suggested-by: Marco Nolden <m.nolden@dkfz-heidelberg.de>
As of CMake 2.8.8, the INCLUDE_DIRECTORIES() command does
not de-duplicate entries. Failure to do so can lead to an extremely
long and repetitive list of -I entries on the command line.
make CUDA_COMPUTE_BUILD_PATH use a relative path to the current
binary directory instead of the current source directory if the source
file considered is in the current binary directory. This is done to
shorten the paths given to the compiler.
This was using nested if's, now it uses elseif to flatten that. It also removes
one "if" from the general "else" branch that checks for Apple, as that has it's
own branch anyway and can't be true at this point.
Make the CMAKE_HOST_* variables always available in the toolchain file.
They are when the file is included in CMakeDetermineSystem.cmake, and
now also here. For the non-cross-compiling case this does not change
anything at all.
Alex
Use of the mis-spelled variable name 'CMAKE_CROSS_COMPILING' was
introduced by commit 4b793ad1 (FindOpenSSL: find cross-compiled OpenSSL
from MinGW, 2012-07-23). Fix the spelling.
Update the CMAKE_<LANG>_LINK_EXECUTABLE rule variable to invoke the
linker directly instead of through the compiler. We already do this
for DLL linking with CMAKE_<LANG>_CREATE_SHARED_LIBRARY.
This also works around a VS 6 cl bug. While invoking the link tool
internally it fails to correctly quote flags like /pdb:... with spaces
in the value.
The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspxhttp://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx
One is created by the compiler (/Fd) and the other by the linker (/pdb).
The two options should not specify the same file. Split them up.
In the VS IDE generators, simply drop ProgramDataBaseFileName to
take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb".
In the Makefile generators, set "/Fd" on the compile line to be
the directory containing object files (with a trailing slash the
compiler will add the "vc$(PlatformToolsetVersion).pdb" filename
automatically). Drop the /Fd option from the exe link command
line and add "/pdb" instead (already done for dll linking).
Update these rules for both MSVC and Intel tools.
Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC
libraries because the generated .pdb files are only from /Fd
and not real linker-generated .pdb files. Update documentation to
clarify that the PDB_* properties are only for linker .pdb files.
This regresses the PDBDirectoryAndName test for STATIC libraries.
Since it is not clear at this time what should be done for STATIC
library .pdb files, comment out the relevant portion of the test
and leave a TODO comment.
This fixes bug #0013609, and is a possible solution to #0012864 as well.
The later will be completely fixed in another way. Both approaches
needs to be implemented because the current one is more automatic.
Inspired-By: Ari
In commit 0c727b90 (install(EXPORT): Force absolute paths for usr-move,
2013-03-08) and commit d4774140 (configure_package_config_file: force
absolute paths for usr-move, 2013-01-24) we supported Linux
distributions implementing the "/usr move" by assuming that installation
to (/usr)?/lib(64)? represents a non-relocatable system package.
When cross-compiling one may prepare a package for installation into a
system location on a target machine but install the package files on the
*host* machine inside another path for use with CMAKE_FIND_ROOT_PATH.
In this case the package development files must still be relocatable.
Handle "/usr move" with a new approach that works with relocatable
files. Teach configure_package_config_file and install(EXPORT) to
generate special logic in a package configuration file or targets file
for installation under (/usr)?/lib(64)?. Teach the file to recognize
when it is loaded through a symlink that refers to the same realpath as
its original install destination. In such a case, use the original
install prefix. Otherwise, compute the prefix relative to the current
file location to make it relocatable.
CPACK_RPM_USER_BINARY_SPECFILE can now be specified on a per-component
basis using CPACK_RPM_<componentName>_USER_BINARY_SPECFILE.
Inspired-By: Theodore Papadopoulo with its patch proposal.
Using XXX as name of the package is ambiguous, since it can be
interpreted as "ALLUPPERCASE" and also as "ExactCase (if the name
is already ALLUPPERCASE)".
After extensive discussion there is the conclusion that ExactCase
is intended, so using a CamelCased name makes that more obvious.
Alex
Modify add_jar to fully use named arguments, rather than cmake
variables, for specifying output names/directories, etc. For backward
compatibility, the old variables are still honored if set, although
named arguments will override them.
Modify add_jar to (partly) use cmake_parse_arguments, and to require
using the named argument list INCLUDE_JARS to specify jar files (or jar
targets) to use as dependencies when creating a jar. This preserves the
ability to have such, while restoring the historic behavior that jar
files listed as sources are ignored. (The code now explicitly ignores
them, however, rather than adding them to an unused local variable, so
that it is more clear that nothing is being done with them.)
In GNU.cmake, -isystem is not used if APPLE is set. However, Clang has
pretty much always supported -isystem, so we should always use it.
In the future, GNU.cmake should do a version check to see if -isystem is
supported.
27e6f6e TI compiler: add automatic detection of prefix and suffixes
b301586 rename TI_DSP toolchain to TI, since it works also for the ARM compiler
12b25df Determine C/CXX/Fortran compiler: fix indentation
7baa55a Determine C/CXX/Fortran compiler: minor restructuring
Use normal custom command dependencies by default. Use the PRE_LINK
approach only to work around what seems to be a bug in msbuild handling
of custom build rules that chain together.
Fix setting classpath when encountering a jar argument to add_jar to
actually set the variable that is used to specify the classpath to
javac, instead of just uselessly appending the jar to
CMAKE_JAVA_INCLUDE_PATH (which is never used again at the point where it
is modified). Also, list jars so specified as dependencies of compiling
the java sources for the jar target.
Brad King
Daniele E. Domenichelli
Marius Schamschula
Daniele E. Domenichelli
Matthew Woehlke
Alex Neundorf
Stephen Kelly
Clinton Stimpson
Rolf Eike Beer
Funda Wang
Bjoern Thiel
Gregoire Lejeune
Alexander Mohr
Andreas Mohr
Matt McCormick
David Golub
Marcel Loose
Mathias Gaunard
Robin Lee
Eric NOULARD
Ben Boeckel
Bill Hoffman
Rex Dieter
James Bigler