Fix the wording of the documentation for CMAKE_PARENT_LIST_FILE to
clarify that it only applies to the include stack in the current
directory. Specify exactly what commands can include files instead of
saying "somehow invoke".
The phrase "flag used" is somewhat imprecise, so extend it to stress
intentions.
Also correct:
- "Flag" => "Flags"
- "[CMAKE_BUILD_TYPE]" => "<CONFIG>"
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.
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
* Clarify accepted values of <LANG> suffix in CMAKE_COMPILER_IS_GNU<LANG>.
* Clarify fact that target property GENERATOR_FILE_NAME usually cannot be
used at configure time.
* Clarify that enable_language() can only be used in global scope of
top-level project using language.
* State that enable_language(... OPTIONAL) currently doesn't work.
* Document regular expression operator precedence.
The GNU compiler front-ends on AIX invoke the linker with flags of the
form "-L/path/to/gnu/runtime/lib" to tell ld where to find the language
runtime libraries. They depend on the default libpath behavior
documented in "man ld" to add the -L paths also to the runtime libpath
so the dynamic loader can find the language runtime libraries. This
differs from platforms whose linkers have distinct -rpath flags that
non-system compilers can use to tell the dynamic loader where to find
their language runtime libraries.
Since commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) CMake always passes "-Wl,-blibpath:" followed by any
project-defined RPATH plus "/usr/lib:/lib" in order to explicitly set
the runtime libpath and avoid getting all the project -L paths in the
runtime libpath. The explicit libpath prevents the GNU compiler runtime
library -L paths from being placed in the libpath and then the dynamic
loader fails to find the language runtime libraries.
CMake already detects the implicit link directories for each language
since commit 07ea19ad (Implicit link info for C, CXX, and Fortran,
2009-07-23). Add the implicit link directories to the explicit runtime
libpath for GNU compilers on AIX to fix this use case.
ba48e63 Generate config-specific interface link libraries propeties.
deb51a7 Remove unused forward declarations.
9712362 Don't allow utility or global targets in the LINKED expression.
faa927e Make sure INTERFACE properties work with OBJECT libraries.
510fdcb Whitelist target types in target_{include_directories,compile_definitions}
4de7178 Ensure that the build interface includes have been added.
df74bc3 Only append build interface include dirs to particular targets.
d4e5c67 Don't keep track of content determined by target property values.
1fb545a Move a special case for PIC from the genex to the cmTarget code.
57175d5 Only use early evaluation termination for transitive properties.
4cf161a Fix determination of evaluating link libraries.
3a298c0 Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
655e98b Ensure type specific compatible interface properties do not intersect.
46e2896 The COMPATIBLE_INTERFACE does not affect the target it is set on.
5f926a5 Test printing origin of include dirs from tll().
7c0ec75 De-duplicate validation of genex target names.
...
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
rejected when the generator doesn't support it, and that two -T options
are always rejected.
This makes
set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
add the equivalent of
set_property(TARGET tgt APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
)
to every target.
If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
cc676c3 OS X: Detect implicit linker framework search paths
2dd67c7 OS X: Detect implicit link directories on modern toolchains
ba58d0c OS X: Link with all framework search paths, not just the last
Previously we hard-coded a list of implicit framework directories but
did not account for CMAKE_OSX_SYSROOT or for changes to the list across
OS X versions. Instead we should automatically detect the framework
directories for the active toolchain.
The parent commit added the "-Wl,-v" option to ask "ld" to print its
implicit directories. It displays a block such as:
Framework search paths:
/...
Parse this block to extract the list of framework directories.
Detection may fail on toolchains that do not list their framework
directories, such as older OS X linkers. Always treat the paths
<sdk>/Library/Frameworks
<sdk>/System/Library/Frameworks
<sdk>/Network/Library/Frameworks # Older OS X only
/System/Library/Frameworks
as implicit. Note that /System/Library/Frameworks should always be
considered implicit so that frameworks CMake finds there will not
override the SDK copies.
Extend documentation for CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES to
explain how it is used by CMake and how it can be influenced by
environment variables.
Inspired-by: Alex Neundorf <neundorf@kde.org>
4ad0233 Remove period at the end of the check message.
50b1ea5 Fix minor typos.
19c3206 Remove unused parameter marker and the unused parameter.
9d462b2 Document that generator expressions can be used in target properties.
daf88c3 Fix punctuation in some variables documentation.
3172cde Fix the layout of the generator expression documentation.
This enables changing the name and output folder of the debug symbol
files produced by MS compilers.
Inspired-by: Thomas Bernard <thomas.bernard@ipetronik.com>
32b7c72 Merge branch 'cmake-platform-info-version' into msvc-compiler-info
f3ddfef Modernize MSVC compiler information files
485a940 VS: Simplify MSVC version reporting
32db033 VS: Remove support for "free" version 2003 tools
403ead6 Document CMAKE_<LANG>_COMPILER_(ID|VERSION) values
8be51f6 Test variables CMAKE_(C|CXX|Fortran)_COMPILER(|_ID|_VERSION)
ec22a9b Cleanly enable a language in multiple subdirectories
66cb335 VS: Detect the compiler id and tool location
89595d6 VS10: Define CMAKE_VS_PLATFORM_TOOLSET variable
965a69d Xcode: Detect the compiler id and tool location
9a9e1ee CMakeDetermineCompilerId: Prepare to detect IDE compiler id
b8b5c83 Re-order C/C++/Fortran compiler determination logic
ee949d8 Remove duplicate 'of' from docs.
ecc1acb Remove incorrect doc string for link type enum
805f5e5 Fix some typos in the docs.
389d423 Add missing whitespace to docs.
Several more recent Visual Studio Express editions are now available and
they support debug builds. Simplify our VS platform files by removing
support for these old tools. If anyone still uses them we can restore
support with a more modern way to test for them.
CMAKE_SHARED_LIBRARY_<lang>_FLAGS has flags on various platforms for a
variety of purposes that are correlated with shared libraries but not
exclusive to them. Refactor generation of these flags to use new
purpose-specific platform variables
CMAKE_<lang>_COMPILE_OPTIONS_DLL
CMAKE_<lang>_COMPILE_OPTIONS_PIC
CMAKE_<lang>_COMPILE_OPTIONS_PIE
Activate the DLL flags specifically for shared libraries. Add a new
POSITION_INDEPENDENT_CODE target property to activate PIC/PIE flags, and
default to true for shared libraries to preserve default behavior.
Initialize the new property from CMAKE_POSITION_INDEPENDENT_CODE to
allow easy global configuration in projects.
Although the default behavior is unchanged by this refactoring, the new
approach ignores CMAKE_SHARED_LIBRARY_<lang>_FLAGS completely. We must
leave it set in case projects reference the value. Furthermore, if a
project modifies CMAKE_SHARED_LIBRARY_<lang>_FLAGS it expects the new
value to be used. Add policy CMP0018 to handle compatibility with
projects that modify this platform variable.
Add a PositionIndependentCode test on platforms where we can get
meaningful results.
4986d52 Use CPACK_xxx and CMAKE_xxx in a consistent way.
f90223c Fix KWStyle warning
47f0dbd CPack add necessary check to detect/warns/error on ABSOLUTE DESTINATION
6ba055b CPack add easy possibility to warn about CPACK_SET_DESTDIR
CMAKE_xxx vars are now used in the CMake-generated cmake_install.cmake
script while CPACK_xxx equivalent vars are used from within CPack.
CPack is responsible for getting/forwarding definitions of
CPACK_xxxx var corresponding to CMAKE_xxxx when invoking
CMake-generated install scripts.
As a consequence:
CMAKE_ABSOLUTE_DESTINATION_FILES
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
may be used from outside CPack as well.
e.g.
cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=1 -P cmake_install.cmake
works as expected.
This allows downstreams to use
set(CMAKE_WIN32_EXECUTABLE ON)
set(CMAKE_MACOSX_BUNDLE ON)
to create executables with the WIN32_EXECUTABLE and MACOSX_BUNDLE
properties set on by default.
eeaaffc find_package: Test error and warning messages in failure cases
52dffb9 Merge branch 'test-CMakeCommands' into find_package-improve-messages
d365104 find_package: Optionally warn when implicitly using Config mode
31ead5f find_package: Reject mixed use of MODULE- and CONFIG-only options
6d83083 find_package: mention requested version number in error message
9c39bbd find_package: add CONFIG mode keyword alias for NO_MODULE
f310f67 find_package: add MODULE mode to use only Find-modules
7d67dcf find_package: improve error message when no Find module is present
978d89b find_package: rename NoModule to UseFindModules
Define variable CMAKE_FIND_PACKAGE_WARN_NO_MODULE for use by a project
that wants to use an explicit mode in every call to find_package in
order to generate more specific failure messages. Word the warning
using the new CONFIG and MODULE mode keywords when the minimum required
version of CMake is new enough to have them. Otherwise word the warning
using the old NO_MODULE mode keyword.
Inspired-by: Alex Neundorf <neundorf@kde.org>
Brad King
Andreas Mohr
Alex Neundorf
Petr Kmoch
Stephen Kelly
Yuchen Deng
Rolf Eike Beer
David Cole
Eric NOULARD
Zack Galbreath
Yury G. Kudryashov