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>
33e6e0b VS6: Add handling of CMAKE_*_LINKER_FLAGS_<CONFIG> variables
152dfda Add additonal tests for the linker flags
20ed496 Add documentation for the missing CMAKE_*_LINKER_FLAGS_* variables
54f7019 Add CMAKE_STATIC_LINKER_FLAGS to CMakeCommonLanguageInclude
2a43c30 Add support for CMAKE_STATIC_LINKER_FLAGS
14bbf83 Unify the way the flags of a static library are read
It's acknowledged that check state should not generally nest,
so it should be cleared when used, for example, in Find* module.
Also, add optional RESET argument to cmake_push_check_state().
32cf738 FindGTK2: Remove GTK2_SKIP_MARK_AS_ADVANCED option
a874142 FindGTK2: Update local changelog
cd2d9c7 FindGTK2: Append _INCLUDE_DIR to var name in _GTK2_FIND_INCLUDE_DIR
732324f FindGTK2: Append _LIBRARY to var name in _GTK2_FIND_LIBRARY
03bd3d1 FindGTK2: Use GTK_XXX_LIBRARY_DEBUG libraries in debug mode
If the GTK_XXX_LIBRARY_DEBUG library is available, it is now used when
linking in debug mode XXX.
A new set of variables GTK_XXX_LIBRARY_RELEASE is added and the
original GTK_XXX_LIBRARY uses the optimized/debug syntax.
-add support for upcoming version 1.7
-improve version selection, use the major and minor of the requested version
to generate the library suffix list
-support detection of release and debug libraries
This patch adds the file CMakePrintHelpers.cmake, which provides
the macros (functions) cmake_print_properties() and cmake_print_variables(),
which are useful e.g. for debugging and make inspecting target (or other)
properties easier.
Alex
This fixes a regression introduced by commit b8af46cb (FindQt4: Don't
fail if certain Qt modules are unavailable., 2013-05-23)
The _FOUND variable is set by the _QT4_ADJUST_LIB_VARS macro, so
invoke that unconditionally, and guard only the set_property calls,
as described in the original bug report (#14165).
bf23891 CPackWIX: Add support for custom WiX templates
155bb01 CMakeCPack: Provide an upgrade guid for WiX
bfa2e29 CPackWIX: Add option to specify the language(s) of the installer
6e51ea9 CPackWIX: Handle multiple shortcuts in the start menu
6d77e1a CPackWIX: Fix MSI package layout regression from parent
8c0e325 CPackWIX: Handle CPACK_PACKAGE_EXECUTABLES (#13967)
If one of the libraries (_DEBUG or _RELEASE) is not set, the value is
set to the value of the other one. FindQt4, from which the macro is
extracted, sets the values to XXX_LIBRARY_{DEBUG,RELEASE}-NOTFOUND
instead. In both cases the XXX_LIBRARY is correct, but using NOTFOUND
makes it easier to understand which one is missing.
Update Tests/CMakeOnly/SelectLibraryConfigurations with the new logic.
Ubuntu install the CUDA libraries into a location that is different
than the default location provided by the NVidia installer. So we
teach the FindCUDA package to also find the Ubuntu install location.
WiX provides a lot of functionality for installers that cannot be
supported (easily) in the default WIX.template.in file.
For most users, the default template should be fine. However if users
want to produce merge modules, include custom actions, etc, this new
option allows for a hook into how the wxs is produced.
If one installs MinGW using the Code::Blocks IDE installer it goes to a
path like "c:\Program Files\CodeBlocks\MinGW", not "c:\MinGW". Use the
CodeBlocks registry entry to get the location.
Signed-off-by: Jason Spiro <jasonspiro4@gmail.com>
In CMakeDetermineCompilerABI we use try_compile with the COPY_FILE
option to get a copy of the compiled binary used to detect the ABI
information. We already tolerate the case when compilation fails.
However, when compilation appears to succeed but does not produce the
expected executable the try_compile command immediately reports an error
because the COPY_FILE fails.
Tolerate COPY_FILE failure without stopping the overall configuration
process by using the try_compile COPY_FILE_ERROR option to capture the
error message. Log the full error to CMakeError.log and simply report
failure to detect the ABI as if compilation had failed.
Teach the RunCMake.Configure test to cover this case and verify that the
messages show up as expected both in stdout and in CMakeError.log.
The VS IDE sets the environment variable VS_UNICODE_OUTPUT when
executing build rules in order to tell MS tools to report output through
a back door instead of through stdout/stderr. Unset this variable so
that CMake can capture or properly redirect all output from processes it
runs even when running inside a VS IDE build environment.
This generalizes the special cases fixed by commit 80d045b0 (When
GetPrerequisites.cmake runs dumpbin while running inside the VS IDE...,
2008-05-01) and commit 44aff73d (ExternalProject: Avoid bleed-through
output when logging, 2011-01-06), so drop special handling of
VS_UNICODE_OUTPUT in those instances.
The command line string passed to javac can exceed the 8191-character
limit on Windows when there are a large number of files to compile.
To avoid this, the list of sources is written to a file which is then
passed to javac as an argfile. Spaces in paths are dealt with by
enclosing each file in quotes, and separating files with a newline.
The linker flags for setting the compatibility and current versions of
libraries on Darwin are set for the supported Fortran compilers.
Set CMAKE_Fortran_CREATE_SHARED_LIBRARY for the NAG Fortran compiler to
have no space after <SONAME_FLAG> so the NAG compiler can parse the
argument correctly.
SelectLibraryConfigurations module currently cache and mark as advanced
the variable ${basename}_LIBRARY.
${basename}_LIBRARY_RELEASE and ${basename}_LIBRARY_DEBUG are usually
cached, because they often come from find_library().
${basename}_LIBRARY on the other hand is always of type
"optimized;${${basename}_LIBRARY_RELEASE};debug;${${basename}_LIBRARY_DEBUG}"
or just "${basename}_LIBRARY_RELEASE" or "${basename}_LIBRARY_DEBUG" if
only one version of the library is not found, if both have the same
value, or if configuration types are not supported.
Caching and marking as advanced just ${basename}_LIBRARY_RELEASE and
${basename}_LIBRARY_DEBUG is enough, just by modifying these two
variables, the user has enough control on finding the library, and
having 3 variables is redundant and confusing.
We support multiple commands per external project step by using
the COMMAND keyword. Document this behavior and show an example.
While at it, document that shell operators and current working
directory behavior is not defined.
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>
Brad King
Patrick Gansterer
Simon Levermann
Stephen Kelly
Alex Neundorf
Rolf Eike Beer
Marius Luca
Raphael Kubo da Costa
Michel Zou
Eric Bélanger
Daniele E. Domenichelli
Vadim Zhukov
Robert Maynard
Adam J. Weigold
Richard Ulrich
Fredrik Axelsson
Jason Spiro
Graham Markall
Eric NOULARD
Marius Schamschula