Create platform information modules Platform/Darwin-Intel-(C|CXX).cmake
and helper module Platform/Darwin-Intel.cmake. Teach existing module
Platform/Darwin-Intel-Fortran.cmake to use the helper too. Move
information from Platform/Darwin-icc.cmake into these files and drop
information already in Platform/Darwin.cmake to avoid duplication.
Some distributions place boost_mpi next to the MPI libraries against
which it was built instead of next to the other Boost libraries. If
find_package(MPI) has already been run prior to find_package(Boost) then
MPI_CXX_LIBRARIES or MPI_C_LIBRARIES may be set to the location of the
MPI libraries. Teach FindBoost.cmake to look there for boost_mpi and
boost_mpi_python after looking next to the other Boost libraries but
not consider the location to be Boost_LIBRARY_DIR.
In CMakeGraphVizOptions.cmake, allow the options GRAPHVIZ_GENERATE_PER_TARGET
and GRAPHVIZ_GENERATE_DEPENDERS to enable the generation of per target graphs
and subgraphs respectively. Both options are TRUE per default to maintain
current behavior.
In commit v2.8.5~176^2~2 (FindOpenSSL: We should only use hints to find
OpenSSL, 2011-03-28) values for HINTS and PATHS of find_* calls were
computed everywhere but only used on Windows. Use them everywhere.
Set a global property in the find_package implementation. Track and
reset that property in the find_dependency macro. Read the property
in FeatureSummary when determining whether to print output.
This means that packages which are found only as dependencies are not
listed by FeatureSummary, but if a project uses find_package elsewhere
directly, then it will be listed by FeatureSummary.
Suggested-by: Alex Merry
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/10640
4271a4ed Help: Add information about INTERFACE_AUTOUIC_OPTIONS.
7935f4de Help: Note that AUTOMOC consumes the defines and includes from targets.
2739a6f9 Help: Move Qt tool invocation information to a generic cmake-qt manual.
dd72b19f Find{Java,JNI}: Use /usr/libexec/java_home on OS X
70560ee1 FindJNI: Overhaul finding JDK libraries and headers on OS X
fcd66a7f Find{Java,JNI}: Consider JAVA_HOME before ENV{JAVA_HOME}
4b3614b2 Find{Java,JNI}: Use ENV{JAVA_HOME} first when set
41d2f2c4 write_basic_package_version_file: use PROJECT_VERSION
7e142c5a project: Manage VERSION variables
16d040c9 project: Add optional LANGUAGES keyword
00007dcc Help: Format project command and variable documentation
Add an introduction about the use of different package types, and the
ability to use Qt 4 and 5 versions together in a single buildsystem.
Add a section about automatic linking of the qtmain.lib library and
how to disable it.
If no JAVA_HOME or ENV{JAVA_HOME} is set then try running this
tool to get the system default Java home.
Suggested-by: Larry Shaffer <larrys@dakotacarto.com>
Drop the hard-coded framework paths and "-framework JavaJM" on APPLE.
Save and restore the value of CMAKE_FIND_FRAMEWORK. Use its value to
choose and order between a normal search for jvm&jawt and a framework
search for JavaVM. When JAVA_HOME is set explicitly by the user then
force a normal search by setting CMAKE_FIND_FRAMEWORK to NEVER. Once
the library is found, set CMAKE_FIND_FRAMEWORK to help find_path locate
the matching headers (framework v. normal).
Add a helper module CMakeFindJavaCommon shared between FindJava
and FindJNI to select a JAVA_HOME value. Prefer a CMake variable
or cache entry first, then an environment variable.
Commit 321e348e (QtAutogen: Use Qt 4 IMPORTED targets to find
executable locations., 2014-01-24) attempted to fix this problem,
but only solved it for a particular ordering of find_package for
Qt 4 and Qt 5.
Add a test to ensure that it works with both orderings.
f7ae1d8a QtAutogen: Short-circut some logic when moc is not available.
4b989d5f QtAutogen: Separate source file processing from AUTOMOC.
c48d877d QtAutogen: Make some methods appropriately file-static.
394e86df QtAutogen: Fix autouic target options in the presence of a config.
964d7f2a QtAutogen: Remove unused variables.
0d934efd QtAutogen: Remove read of SKIP_AUTOUIC target property.
321e348e QtAutogen: Use Qt 4 IMPORTED targets to find executable locations.
e96683b0 Qt4: Use IMPORTED executable names with custom commands.
e6182f5d Qt4: Create IMPORTED executable targets for all Qt executables.
Finding Qt 5 can overwrite the QT_MOC_EXECUTABLE variable with the
moc from Qt 5. Use the IMPORTED target with the explicit version in
the name to avoid that.
a432b93b file DOWNLOAD: Display the curl result status when a hash mismatch occurs.
1cb9ef81 file DOWNLOAD: Test non-zero return status.
f73f0fb3 file DOWNLOAD: Add test for bad hash.
b5e2265f ExternalProject: Reattempt download when verification fails.
Introduce policy CMP0047 to control resetting the id for
compatibility.
De-duplicate content in the QNX platform file by including the GNU
one. QNX is a form of GNU platform.
Do not clear CMAKE_SHARED_LIBRARY_${lang}_FLAGS variables. They
are populated again later by the Compiler/GNU.cmake file anyway.
Modify the CMAKE_CXX_COMPILE_OBJECT variable only when the QCC
compiler id is in use, and the language is CXX. Use the QNX
recommended flag for QCC instead of the gcc compatible -x flag.
Populate new module files to handle system includes and depfiles
when using the QCC compiler.
Remove code which unsets the system include and depfiles related
variables. When a GNU driver is used instead of the QCC one, the
appropriate flags will be used. These variables were previously
cleared for lowest-common-denominator compatibility with both
drivers.
In commit 2412d9bc (Use 'uname -m' for processor on Cygwin, 2010-09-21)
it was pointed out that POSIX requires 'uname -m' but not 'uname -p':
http://www.opengroup.org/onlinepubs/9699919799/utilities/uname.html
On OS X x86_64, 'uname -p' returns i386 while 'uname -m' returns x86_64.
Since the latter is the POSIX-compliant option trust its value.
However, on OS X ppc, 'uname -m' returns 'Power Macintosh' so add a
special-case to convert that to 'powerpc'.
When downloading an URL with ExternalProject, reattempt the download three
times if the file hash verification fails.
The re-attempt is limited to non-local URL's. The same download CMake script
is re-used after removing any file that resulted from the previous download
attempt. Up to three re-attempts are performed.
When not installing in /usr (i.e. /usr/local) on Debian/Ubuntu, the
multiarch path is not in ldconfig path, and therefore libraries cannot
be found, unless the user manually modifies the files in
/etc/ld.so.conf.d, in order to include /usr/local/lib/<arch>.
This patch fixes this issue by using "lib/<arch>" only if the user is
installing the software in /usr, and uses "lib" in all the other cases.
Remove independent doc listing for Qt4ConfigurationSettings, Qt4Macros
and UseQt4. These are implementation details.
Recommend the use of IMPORTED targets.
Remove references to the UseQt4 file, which is obsolete in light of
the IMPORTED targets.
Add documentation for automatic tool invocation and options.
Remove reference to variables which should not be needed in modern
implementations.
Commit 5bb53f6b (cmTarget: Deprecate COMPILE_DEFINITIONS_ properties
with a policy., 2013-12-30) deprecated the config-specific
COMPILE_DEFINITIONS_* properties in favour of using generator
expressions.
Set the directory property in UseQt4.cmake to match the
INTERFACE_COMPILE_DEFINITIONS on the Qt4::QtCore and Qt5::Core
IMPORTED targets. Setting QT_NO_DEBUG is sufficient because qglobal.h
sets the corresponding QT_DEBUG definition if required.
73e9340 get_target_property: Error on non-existent target.
ab9f58f FindQt4: Ensure target exists before calling get_target_property.
37ebeb9 FindQt4: Fix use of get_target_property to use actual target name.
6aabb6a Genex: Use case-sensitive comparison for COMPILER_ID.
5bb53f6 cmTarget: Deprecate COMPILE_DEFINITIONS_ properties with a policy.
There are many style errors in these files. This patch fixes only
the syntactical errors.
The script which ported these to rst tripped on some incorrectly
formatted blocks in the original input documentation. Use a new
script to find problematic code (and then fix them manually):
#!/usr/bin/env python
import os
rootDir = '.'
def checkFile(fname):
f = open(fname)
lines = f.readlines()
started = False
counter = 0
for l in lines:
if "#" in l:
started = True
elif started:
return
lin = l.find("(")
if lin != -1 and l.find(")", lin) == -1 and \
not "(To distribute this file outside of CMake, substitute the full" in l:
for lp in lines[counter+1:]:
if lp == "# ::\n":
print "\n\n######### " + fname + "\n\n"
print ''.join(lines[max(counter-2, 0):counter+6])
break
elif lp == "#\n" :
continue
break
counter += 1
for dirName, subdirList, fileList in os.walk(rootDir):
for fname in fileList:
checkFile(os.path.join(dirName, fname))
There is not really any need to. Downstreams can either rely on it
being provided by CMake, or copy and distribute it.
Change the documented include for the find_dependency macro.
Added a new variable CPACK_WIX_PATCH_FILE that users can point at an
XML patch file. Fragments defined within the patch file will be inserted
at supported insertion points (currently Component, File and Directory).
If TortoiseSVN is not installed in the default path, the svn executable
installed by TortoiseSVN is not found.
Using the registry key should always find it.
Xcode 5.1 output no longer puts "./" in the path to the linker output
for the CompilerId test binary. Update our regex to match the path
with or without the component.
In commit ecd84147 (Fortran: Detect pointer size in gfortran on MinGW,
2011-11-29) we started testing for __SIZEOF_POINTER__ but not all GNU
Fortran compilers define this. Check also for __SIZEOF_SIZE_T__ which
at least one version of gfortran defines without also defining
__SIZEOF_POINTER__.
In the code path for launching the VS IDE tools, avoid using
CMAKE_MAKE_PROGRAM. Instead use the variables CMAKE_VS_DEVENV_COMMAND,
CMAKE_VS_MSBUILD_COMMAND, and CMAKE_VS_MSDEV_COMMAND to lookup the
location of the build tool needed. Choose the proper tool based on
availability and necessity for the language (e.g. Intel Fortran must
build with devenv.com and not MSBuild.exe).
Creates a hierarchy of WiX features from CPack components and component groups.
Switch to the FeatureTree UI in case components have been defined.
Handles the component REQUIRE and HIDDEN options
and the component group EXPANDED option.
The previous version added -jN to the make invokation if UNIX
was set, but this was true also when cross compiling.
What we are actually interested in is CMAKE_HOST_UNIX, i.e.
whether the build host is UNIX.
Or we should check more exactly what CMAKE_MAKE_PROGRAM is.
Alex
Add an architecture-specific library directory path suffix for each
component. Use different search path for SDL_sound. Project files in
VisualC directory suggest that a win32lib will hold the libraries.
Reported-by: Paul Hampson <Paul.Hampson@Pobox.com>
This variable can be useful in cross-compiling contexts where the
sysroot is read-only or where the sysroot should otherwise remain
pristine.
If the new CMAKE_STAGING_PREFIX variable is set, it is used instead
of CMAKE_INSTALL_PREFIX when generating the installation rules in
cmake_install.cmake.
This way, the CMAKE_INSTALL_PREFIX variable
always refers to the installation prefix on the target device, regardless
of whether host==target.
If any -rpath paths passed to the linker contain the CMAKE_STAGING_PREFIX,
the matching path fragments are replaced with the CMAKE_INSTALL_PREFIX.
Matching paths in the -rpath-link are not transformed.
The cross-prefix usr-move workaround is assumed not to require extension
regarding CMAKE_STAGING_PREFIX. The staging area is a single prefix, so
there is no scope for cross-prefix symlinks. The CMAKE_INSTALL_PREFIX
is still used to determine the workaround path, and that variable
remains the relevant one even if CMAKE_STAGING_PREFIX is used. If the
generated export files are deployed to the target, the workaround
will still be in place, and still be employed if required.
7cd65c9 Add CMAKE_SYSROOT variable to set --sysroot when cross compiling.
5096967 Allow toolchain files to specify an external toolchain.
76552d5 Add compiler target compile options.
f41ecd1 CMakeDetermineCompilerId: Look for internal file only on host
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.
Clang can compile code, but uses the gcc tools for other tasks such
as linking. The -gcc-toolchain option can be used for that, but
generalize so that other compilers can be treated the same.
If such a location is specified, use it as a hint for finding
the binutils executables.
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.
When cross-compiling with clang, use the CMAKE_${lang}_COMPILER_TARGET
as the _CMAKE_TOOLCHAIN_PREFIX to find the appropriate binutils.
When cross-compiling with QNX qcc, use the CMAKE_${lang}_COMPILER_TARGET
to set the appropriate _CMAKE_TOOLCHAIN_PREFIX.
The find_file this module uses to locate the compiler id source file
must always look on the host and never in CMAKE_FIND_ROOT_PATH, even
when a toolchain file has
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Add NO_CMAKE_FIND_ROOT_PATH to the find_file call to avoid rerooting.
4cce44b Help: Document the CMAKE_MAKE_PROGRAM variable in more detail
558c74d VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generators
5229f2d Tests: Do not use an explicit make program for VS generators
72dd738 Tests: Fix MFC test heuristic for empty CMAKE_TEST_MAKEPROGRAM
fd6076d Tests: Pass CMAKE_MAKE_PROGRAM instead of --build-makeprogram
68031ab Tests: Configure SubProject-Stage2 test more robustly
003d10c Tests: Simplify VSExcludeFromDefaultBuild configuration
e47d934 Tests: Simplify VSProjectInSubdir configuration
e965cb1 Tests: Simplify CTest.BuildCommand.ProjectInSubdir configuration
72bf255 Tests: Pass --build-options to every test
4d1d772 ctest: Teach --build-options to allow zero options
96966b5 ctest: Make the --build-makeprogram optional for --build-and-test
91a0211 Simplify some calls to cmGlobalGenerator::Build
123a060 Teach GenerateBuildCommand to find its own make program
5f5c92b VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdev
4ac75fd Prefer CMAKE_MAKE_PROGRAM over CMAKE_BUILD_TOOL (#14548)
...
Manually revise the .rst format of the documentation. Use inline
literal quotes appropriately in paragraph text. Move the :: literal
block openers to the end of the preceding paragraphs. Convert the
command signature documentation and examples to cmake code-block
directives.
Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the
cmGlobalGenerator::FindMakeProgram method for VS generators to use their
internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a
normal variable for use by project code, but do not cache it. This will
allow CMake and CTest to select the proper tool at build time.
Historically these were both added for the Makefile and Visual Studio
generators, respectively. Later the VS generators started using the
CMAKE_MAKE_PROGRAM cache entry to find the IDE build tool, and the
CMAKE_BUILD_TOOL was simply set as an alias.
Fix the documentation to explain that CMAKE_MAKE_PROGRAM is the modern
variable and that CMAKE_BUILD_TOOL is the compatibility alias, not the
other way around. Replace uses of CMAKE_BUILD_TOOL with
CMAKE_MAKE_PROGRAM in CMake-provided modules. Nothing needs to lookup
CMAKE_BUILD_TOOL in the cache, so simply set it as a normal variable.
The internal variables CPACK_ADDCOMP_COMPONENTS,
CPACK_ADDCOMP_STR and CPACK_ADDCOMP_UNAME were being needlessly
exported to CPackConfig.cmake.
Prefixing them with an underscore prevents this.
CPACK_ADDCOMP_STR was particularily problematic since it contains
unescaped quotes.
Since commit 7d47c693 (Drop compatibility with CMake < 2.4, 2013-10-08)
we no longer need to use the configure_file IMMEDIATE option to support
compatibility modes less than 2.0.
Allow ExternalData_URL_TEMPLATES to be empty if a value for
ExternalData_OBJECT_STORES is provided. Assume in this use case that
the object stores will already contain all needed objects. Extend the
Module.ExternalData test to cover this case (all objects in stores).
Extend the RunCMake.ExternalData test to cover the non-failure message
case when stores are provided without URL templates.
Manually revise the .rst format of the documentation. Use inline
literal quotes appropriately in paragraph text. Move the :: literal
block openers to the end of the preceding paragraphs. Convert the
command signature documentation and examples to cmake code-block
directives.
On biarch architecture, CMAKE_SYSTEM_PROCESSOR might be a 64bit one
while the system 32bit one. Take this into consideration while looking
for Java library directory.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718290
The set() call for this variable left out the CACHE keyword. It does
not need to be cached anyway, so drop the other CACHE set() signature
arguments.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722475
Reported-by: Modestas Vainius <modax@debian.org>
Inspired-by: Mathieu Malaterre <malat@debian.org>
As mentioned in commit 4693cf84 (Xcode: Detect new default locations of
Xcode 4.3 bits and pieces) PackageMaker was split out of Xcode 4.3 and
above into a separate Auxiliary tools package. Since Xcode 5.0 or so,
Apple no longer distributes PackageMaker as part of the available
development tools so it can only be obtained from old packages.
Disable the CPACK_BINARY_PACKAGEMAKER option by default as is the case
for most other tool-dependent generators.
In certain scenarios, it is preferable to keep a 'dirty' install prefix
than to clear it, and to expect that content will not be found there.
Add a CMAKE_FIND_NO_INSTALL_PREFIX variable that can be set to disable
searching the install prefix.
9c87d9c Add automatic rcc invocation for Qt.
84218e1 Add automatic uic invocation for Qt.
94a0ca6 Record which files are skipped by automoc.
18fb758 Run the main executable created in the autogen tests.
e485ba1 Rename the QtAutomoc tests to QtAutogen.
7ce65c3 Add extra checks for the AUTOMOC target property.
32771fc Update output messages for generic use.
f371ab5 Rename RunAutomoc to RunAutogen.
85b3d6e Extract an SetupAutoMocTarget method.
ca124a1 Rename the AutomocInfo.cmake file to be more generic.
a342c9f Move some makefile definitions up away from moc-specific code.
98632ef Add the AUTOGEN_TARGETS_FOLDER and obsolete AUTOMOC_TARGETS_FOLDER.
63378ba Rename some variables to reflect broader scope.
97f1aa3 Rename method to reflect generic use.
4abb111 Rename local variable to reflect generic use.
03878c9 Move variable set to where it is used.
...
3e04946 Require CMAKE_<LANG>_COMPILER to be found as a full path
6007f7c CMakeDetermineCompilerId: Always use compiler detected from IDE
332771c CMakeDetermine*Compiler: Remove temporary cache entry
All generators now support detection of the full path to the compiler, so
require it to be so. This will allow CMake<LANG>Information.cmake and
other logic to assume the full path to the compiler tool is available.
The Makefile generators already rejected CMAKE_<LANG>_COMPILER values
that did not name an existing compiler. Extend this error message to
all generators, make it occur as early as possible, and improve the
message with advice about how to set the compiler. If the full path to
the compiler is not known, finish enabling languages with a fatal error
so configuration does not continue.
For now, allow the RC language compiler to not be a full path. Later we
will need to detect the full path to "rc" under the VS IDE.
Add a RunCMake.CompilerNotFound test to cover failure cases.
Fix the RunCMake.CompilerChange test EmptyCompiler case to work
when configuration does not continue past enable_language.
When compiler id detection also provides a CMAKE_<LANG>_COMPILER
value, use it unconditionally. It is known to be the compiler
that is actually in use by IDE builds in VS and Xcode. Do not
let a stray cache entry try to say otherwise.
Teach the ctest_update implementation to use the p4 command-line
client to perform updates and extract the list of changes.
Add a CTest.UpdateP4 test like those that exist already for the other
version control tools. Make the test available when p4 and the p4d
server are found. During the test launch p4d in the background to
serve a repository from the test directory. Then direct the client
toward this server for the duration of the test.
One way to use clang as a cross-compiler is to create
a symlink named <target>-clang, which is equivalent to
running
clang -target <target>
Extract the toolchain prefix to find the binutils executables.
When the user or toolchain file sets CMAKE_<LANG>_COMPILER to a name
without a path we use find_program with CMAKE_<LANG>_COMPILER_WITH_PATH
to search for the tool. Remove the temporary cache entry afterward to
avoid exposing it to projects. It is not set by other logic paths so no
one should be using it.
The source files are already processed by cmQtAutomoc to look for
moc includes, so extend that to also look for ui_ includes and
find corresponding .ui files to process.
This replaces the need to invoke qt4_wrap_ui().
As the ui files are not likely to be part of the SOURCES of the
target, store the options associated with them separately in the
cmMakefile for querying during the autogen run.
* added CUDA_TOOLKIT_TARGET_DIR CMake variable that used
to locate headers and libraries for target platform
* added CUDA_TARGET_CPU_ARCH which is set to ARM for
arm cross-compilation and is used to add
--target-cpu-architecture NVCC flag
Drop all behavior activated by setting CMAKE_BACKWARDS_COMPATIBILITY to
a value lower than 2.4, and generate an error when projects or the user
attempt to do so. In the error suggest using a CMake 2.8.x release.
Teach cmake_minimum_required to warn about projects that do not require
at least CMake 2.4. They are not supported by CMake >= 3.0.
Replace the documentation of CMAKE_BACKWARDS_COMPATIBILITY with a
reference to policy CMP0001.
Even though this variable gets set to CMAKE_<LANG>_COMPILER-NOTFOUND when
the compiler is not found, CMake<LANG>Compiler.cmake gets removed by
cmGlobalGenerator::EnableLanguage so in try compiles the value is empty.
Quote references to the variable in
Modules/CMake(C|CXX|Fortran)Information.cmake
Modules/CMakeDetermineCompilerId.cmake
to avoid dropping arguments from commands that expect them.
Add "Module Documentation" and "Find Modules" subsections. Add to
Modules/readme.txt a textual reference to the cmake-developer.7 manual
and, while at it, fix the wiki URL domain.
Move all content from Modules/readme.txt except for the link to the
module maintainers wiki page into "Help/manual/cmake-developer.7.rst".
This produces some invalid reStructuredText markup to be fixed in a
future commit.
Previously if headers required to check the size of a type can be
compiled with C++ compiler only, the check would fail because the C
compiler fails. As a consequence, HAVE_${VARIABLE} would be set to
false, and ${VARIABLE} will be empty.
Teach CHECK_TYPE_SIZE to accept a new optional argument LANGUAGE
that allows one to explicitly set the compiler to use. The new
signature is therefore:
CHECK_TYPE_SIZE(TYPE VARIABLE [BUILTIN_TYPES_ONLY]
[LANGUAGE <language>])
Teach CMakeDetermineCompilerId to skip trying to build a .vfproj
file for Intel Fortran under Visual Studio 6. The msdev command-line
build produces a popup error dialog that hangs the configuration.
In generators such as Ninja that can run multiple "cl" processes that
refer to the same compiler .pdb file (/Fd) at the same time, MSVC from
Visual Studio 2013 complains:
fatal error C1041: cannot open program database '.../vc120.pdb';
if multiple CL.EXE write to the same .PDB file, please use /FS
According to "cl /?":
/FS force to use MSPDBSRV.EXE
Add the flag to compilation lines for this compiler version just after the
/Fd option.
d14898b Intel: Fix detection of MSVC version simulated by pre-11.0 Fortran
a85e17e Intel: When simulating MSVC, re-use Windows-MSVC (#14476)
af40e8c VS: Detect Intel Fortran compiler id and version
b8522a8 VS: Expose Intel Fortran .vfproj format version to CMake language
2d36c9a CMakeDetermineCompilerId: Fix Intel Fortran compiler id detection
a6fd17c VS: Fix CMAKE_<LANG>_COMPILER detection with Intel toolset (#14471)
The Intel Fortran 10 64-bit compiler incorrectly defines _MSC_VER to its
own version (1020) instead of the underlying MSVC tools version. Since
we expect the compiler to be used only with VS >= 7 tools, assume MSVC
version 13.0 if _MSC_VER is not greater than 1300.
Teach CMake(C|CXX|Fortran)CompilerId* to report the MSVC version
simulated by the Intel compiler, if any. Refactor the Windows-Intel
platform information helper module to load Windows-MSVC instead of
duplicating the information. Teach Windows-MSVC to understand when
it is loaded as the simulated Fortran compiler (its preprocessor is
simulated).
It designed to search for implementation of backtrace(3) routine.
Currently it is used in OpenBSD Ports for building Clementine
music player.
A lot of input from brad.king@ and neundorf@.
The Intel Fortran compiler needs the /fpp option to enable C
preprocessing. Without the option the compiler may warn and ignore
preprocessor lines instead of failing with an error. Detect the
warning and treat it as failure so that we move on to try /fpp and
detect the correct id. Without this it works only by luck because
Intel is the first compiler id in our detection source file.
Drop #end and #module. Convert #section to a subsection header.
Convert #variable to the cmake domain "variable" directive.
Convert #macro to the cmake domain "command" directive.
Perform minor formatting fixes in text near these changes.
Compilers for languages other than C and C++ on OS X may not understand
the -F framework search flag. Create a new platform information
variable CMAKE_<LANG>_FRAMEWORK_SEARCH_FLAG to hold the flag, and set it
for C and CXX lanugages in the Platform/Darwin module.
Reported-by: Vittorio Giovara <vittorio.giovara@gmail.com>
f973737 GenerateExportHeader: Port to use message(DEPRECATION)
f69606d Qt4Macros: Port to use message(DEPRECATION)
509c142 message: Add a DEPRECATION mode
7efef02 FindGTK2: Add tests for components and targets in gtk and gtkmm modules
95fc47a FindGTK2: Make pangocairo and cairo optional dependencies
26f790f FindGTK2: Change extra includes -> optional
24e0272 FindGTK2: do not skip target creation if optional dependencies are not found
d5f130c FindGTK2: Refactor _GTK2_ADJUST_LIB_VARS into _GTK2_ADD_TARGET
fffbd72 FindGTK2: Do not add freetype includes if they are not found
b69720d FindGTK2: Add libraries to the GTK2_LIBRARIES variable only when found
425ec40 FindGTK2: Do not link libfreetype
e9f46df FindGTK2: Add config directories only if different from include ones
56a79e1 FindGTK2: Set INTERFACE_COMPILE_DEFINITIONS target property only if not empty
4b47586 FindGTK2: Add check to ensure that target exists
61242cc FindGTK2: Fix gmodule, glibmm, pangoft2, and pangoxft targets
4b876de FindGTK2: Link freetype libs to targets including freetype includes
67e761f FindGTK2: Small cleanup
682eea3 FindGTK2: Do not require the GTK_ prefix in all the internal functions
0bc3763 FindGTK2: Better handling of include directories
...
54ef2be Haiku: Include files cleanup in cmCTest
38d5555 Haiku: Remove outdated preprocessor checks
1dc61f8 Haiku: Remove use of B_COMMON_DIRECTORY
7ebc1cb Haiku: Several fixes to platform module
1763c31 Set policy CMP0025 to NEW while building CMake itself
aa53ee5 Add policy CMP0025 for Apple Clang compiler id compatibility
ab65862 Clang: Add separate "AppleClang" compiler id
3d8356d Clang: Support Windows variants for GNU and MSVC (#13035, #14458)
51ab85c CMakeDetermineCompilerId: Add notion of "simulated" id/version
be10826 CMakeDetermineCompilerId: Fix local var init
This function avoids creating the targets when the required
dependencies were not found.
Also fix some wrong dependency and some typo.
${FREETYPE_INCLUDE_DIR_ft2build} ${FREETYPE_INCLUDE_DIR_freetype2} are
now required for gtkmm component
Some libraries (e.g. gio) are not necessary, and often not available
with older GTK2 versions, therefore GTK_LIBRARIES should not contain
GTK2_XXX-NOT_FOUND for these libraries.
As discussed on the mailing list, freetype includes used in GTK2
headers libraries do not require to link the library explicitly (even
though it is already linked by GTK2 libraries.
Also remove _GTK2_ADD_TARGET_LIBRARIES no longer used and use
${FREETYPE_INCLUDE_DIR_ft2build} ${FREETYPE_INCLUDE_DIR_freetype2}
variables instead of ${FREETYPE_INCLUDE_DIRS}
Also add a comment explaining the purpose of the include/SDL* path
suffixes. As explained in commit 7cb51739 (FindSDL: Restore
accidentally dropped search paths (#13651), 2012-11-05) the include/SDL*
path suffixes are for looking in the ENV{SDLDIR} location.
Inspired-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Do not define BEOS anymore (this includes workarounds which we don't
need most of the time in Haiku, so we prefer opt-in IF(HAIKU) in the
cmake files instead).
* On the other hand, do define UNIX (we are trying to be compliant) and
HAIKU (there is still a number of things we don't do like the
average UNIX clone)
* Do not use UnixPaths, as our filesystem hierarchy isn't anything like
what it expects.
* Do not use -nostart, which the compiler doesn't know about anymore.
This used to be an Haiku extension to gcc, and is equivalent to
-shared which is the default gcc option.
* While "dl" functions are provided in libroot, this is always
implicitly linked so there is no need to tell cmake about it.
* Forcing position-independent code is not needed, so remove it.
* On the other hand, include appropriate linker options for executables
and shared libraries.
* Support for the two available compilers in Haiku (gcc2 and gcc4) and
pick the right headers and libraries according to the currently
selected one.
* With the adoption of the package manager, the directory layout was
changed. Tell cmake where to look for header files and libraries.
* As we don't define BEOS anymore, enable the workaround we still need
for HAIKU as well. This is the lack of a libm (it is part of the
implicitly linked in libroot)
Applied-by: Rolf Eike Beer <eike@sf-mail.de>
Previously if headers required to check if a struct has a member can be
compiled with C++ compiler only, the check would fail because the C
compiler fails. As a consequence, the result variable would be set to
false, even if the struct has that particular member.
Teach CHECK_STRUCT_HAS_MEMBER to accept a new optional argument LANGUAGE
that allows one to explicitly set the compiler to use. The new
signature is therefore:
CHECK_STRUCT_HAS_MEMBER (<struct> <member> <header> <variable>
[LANGUAGE <language>])
Apple distributes their own Clang build with their own version numbers
that differ from upstream Clang. Use the __apple_build_version__ symbol
to identify the Apple Clang compiler and report the Apple Build Version
as the fourth version component in CMAKE_<LANG>_COMPILER_VERSION. Add
Compiler/AppleClang-<lang> and Platform/Darwin-AppleClang-<lang> modules
that simply include the upstream equivalents.
Fix comparisons of CMAKE_<LANG>_COMPILER_ID to Clang in CMake's own
source and tests to account for AppleClang.
5f11b8d Eclipse: add version 4.3 for completeness
2b63734 Eclipse: print different message if CMAKE_ECLIPSE_VERSION is already set
1ff8c21 CMakeFindEclipse: use lowercase for macro calls
Teach the compiler identification preprocessor tests to report when
Clang simulates MSVC, and what version. If not MSVC, assume GNU.
Teach compiler information modules Clang-(C|CXX) to recognize when Clang
simulates MSVC and skip loading the GNU information.
Teach the Windows-MSVC platform information to recognize when it is
loaded as the simulated compiler and use that version information
instead of the real compiler's (different) version scheme.
Add platform modules Windows-Clang-(C|CXX) and support module
Windows-Clang to load either Windows-MSVC or Windows-GNU and wrap
the corresponding information macros.
Some compilers try to simulate other compilers as a drop-in replacement
supporting all the same command-line options and predefined preprocessor
macros. In such cases it will be useful to have CMake load the compiler
information files for the simulated compiler instead of duplicating the
information. Teach CMakeDetermineCompilerId to extract the simulated
compiler id and version when the compiler id detection provides it.
In Modules/Platform/Darwin.cmake set CMAKE_SYSTEM_FRAMEWORK_PATH to
include framework directories from inside the system SDK corresponding
to CMAKE_OSX_SYSROOT.
Suggested-by: Sean McBride <sean@rogue-research.com>
The subsystem must be set to WINDWOSCE for some SDKs to link an
executable. Set it to 9 for VS2005 and to 8 for VS2008, since the
value differs between the different Visual Studio versions.
In commit bd827f98 (Use COFF file header header for architecture
detection, 2013-08-05) the MSVC_<lang>_ARCHITECTURE_ID value computed by
CMakeDetermineCompilerId.cmake changed for WinCE architectures to be the
exact architecture read from the PE header. Fix platform preprocessor
definitions in Modules/Platform/Windows-MSVC.cmake to correspond to the
architecture family (ARM or SHx) instead of the specific architecture.
In commit 8fcf0ab0 (Add support for new Windows CE compiler, 2013-08-04)
we made corelibc conditional on the MSVC version, but the version value
was incorrect. Update it to use corelibc for VS 2008 and below.
When FindHDF5 was first added in commit e6734068 (Add HDF5 find
module..., 2009-08-24) it contained a workaround for a bug in
SelectLibraryConfigurations that did not transform lists correctly.
That bug was fixed by commit 5797512c (SelectLibraryConfiguration:
generate correct output when input vars are lists, 2012-07-28). Then
refactoring in commit 04d4dc33 (SelectLibraryConfigurations: Use
-NOTFOUND instead of copying the vars, 2013-07-08) changed undocumented
behavior on which the original workaround relied. The result puts
entries like HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND in HDF5_LIBRARIES.
Fix this by dropping the original workaround since the underlying issue
has been fixed anyway. Use the HDF5_${LIB}_LIBRARY selected by the call
to select_library_configurations directly.
In commit 2a797539 (FindPNG: improve library detection, 2013-07-27) we
split the search for PNG into separate PNG_LIBRARY_DEBUG and
PNG_LIBRARY_RELEASE variables. However, if a project or user sets the
old PNG_LIBRARY value we must honor it instead of searching.
While at it, mark PNG_LIBRARY_RELEASE and PNG_LIBRARY_DEBUG as advanced
and remove a stray debug message.
CMake's intended interface for linking to explicit object files (marked
with EXTERNAL_OBJECT) is that only those listed as target sources should
be linked. Drop FindCUDA's attempt to hide the .obj files from VS IDE
project files, which depends on VS-version-specific behavior of linking
custom command outputs that happen to be named "*.obj". CMake puts
external object files in a dedicated source group anyway.
In commit fb9f73de (MSVC: Invoke 'link' directly for executables,
2013-04-08) we forgot to remove the /link option handling added by
commit e31df039 (Ninja: move <OBJECTS> in front of the first linker
option, 2012-09-27) to the Platform/Windows-MSVC module. Drop it now.
When compiling the 64 bit version of wxWidgets using nmake the library
folders become vc_x64_lib and vc_x64_dll and can coexist with the win32
version.
When the VS IDE build output setting
Tools -> Options -> Projects and Solutions ->
Build and Run -> MSBuild project output verbosity
is set to "Diagnostic" the build output contains a " (TaskId:###)"
suffix on the CMAKE_<lang>_COMPILER= line used to extract the compiler
executable location. Strip this suffix before checking that the
reported location exists.
Follow-up to commit 4a015f77 (OpenBSD: Add paths for Tcl/Tk 8.4/8.5,
2012-12-03): those paths added for OpenBSD also work on other BSDs, some
of which are already using version 8.6 of Tcl/Tk.
After building the test binary tell find_program to search for it with
the ${CMAKE_EXECUTABLE_SUFFIX} so that the .exe can be found. Since
find_program is normally used to locate host tools while cross-compiling
it needs this hint to find the target binary.
Suggested-by: Denis Barbier <bouzim@gmail.com>
Since commit 95f78e08 (OS X: Search for SDK based on deployment target,
2013-08-02) we select the default OS X SDK path to match the deployment
target. Fix this behavior in the case that the matching SDK does not
exist and fall back to the SDK for the current host OS X version.
This simplifies maintenance as most patterns will be for both modules and may
be added at a central place.
While at it add error patterns for XL and BCC.
c90151b VS: Unify how the name of the generator is specified
3873d29 Fix detection of WinCE SDKs with 64bit verion of CMake
40a4302 VS12: Remove duplicated overload of UseFolderProperty()
b02f09d VS: Replace ArchitectureId with PlatformName
4b15dc8 VS: Set CMAKE_VS_PLATFORM_NAME for VS7 and VS71 too
60e568c VS10: Do not set the TargetMachine when detecting the compiler
dfbfe6f VS6: Hardcode id_machine_6 for compiler detection
Teach modules CMakeDetermineCompiler and CMakeUnixFindMake to ask Xcode
where to find the compiler or make tools, using 'xcrun --find', if none
is found in the PATH. Teach module Platform/Darwin to add the path to
the SDK to CMAKE_SYSTEM_PREFIX_PATH so that find_* command look there.
Also add the SDK /usr/include directory to the implicit include list in
CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to suppress explicit -I
options for it.
bf5a5bc bootstrap: Do not suppress CMAKE_OSX_SYSROOT if CFLAGS have -isysroot (#14324)
95f78e0 OS X: Search for SDK based on deployment target (#14324)
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
The Microsoft linker is intelligent enough to detect the target
machine type depending on the input files. This allows us to
get the target architecture from the compiler instead of
maintaining the mapping to the platform name.
When available, use CMAKE_OSX_DEPLOYMENT_TARGET instead of the host OS X
version to select the default SDK. This makes sense because one should
use the SDK matching the deployment target.
Suggested-by: John Ralls <jralls@ceridwen.us>
Brad King
Daniel Pfeifer
Stephen Kelly
Timo Rothenpieler
Nils Gladitz
Alex Neundorf
Ho Cheung
Gereon Kremer
Matt McCormick
Daniele E. Domenichelli
Joe Abbey
Clinton Stimpson
Ruslan Baratov
Dimitri John Ledkov
Vadim Zhukov
Ted Kremenek
Simon Sasburg
Rolf Eike Beer
Flynn Marquardt
Julien Schueller
Benjamin Eikel
Arnaud Desmier
Rolf Eike Beer
Modestas Vainius
Peter Kümmel
Dragos Carp
Pedro Navarro
Vladislav Vinogradov
Kitware Robot
Leszek Swirski
Adrien Destugues
William Orr
Patrick Gansterer
Simon Levermann
Marius Luca
Raphael Kubo da Costa
Michel Zou
Eric Bélanger