8bcec4d2 Help: Add notes for topic 'GNUInstallDirs-special-prefixes'
c8bd37ec GNUInstallDirs: Add special cases for certain prefixes
5f30f175 GNUInstallDirs: Add test cases
54676a0e Help: Add notes for topic 'ConcurrentFortran-compiler-id'
7cd539b1 Add support for Concurrent Fortran 77 Compiler
0d204c1c CMakeDetermineCompilerId: Try matching compiler output to detect id
5f0dad75 CMakeDetermineCompilerId: Refactor id build/check loop logic
c65a060e CMakeDetermineCompilerId: Optionally try some flags before no flags
The Concurrent Fortran compiler (ccur.com) is available on Linux and can
be used much like the GNU Fortran compiler. Currently it has no
preprocessor symbols to identify it so we need to detect it by matching
compiler output.
Suggested-by: Anthony Ette <Anthony.R.Ette@controlsdata.com>
Create a <LANG>_COMPILER_LAUNCHER target property (initialized by a
CMAKE_<LANG>_COMPILER_LAUNCHER variable) to specify a compiler launcher
tool. This will supersede the CMAKE_<LANG>_COMPILER_ARG1 approach to
using such tools. The old approach set CMAKE_<LANG>_COMPILER to the
launcher tool while the new approach leaves this variable set to the
actual compiler.
Implement this property for Makefile and Ninja generators. It cannot be
implemented for VS or Xcode generators as the IDE build tools offer no
such hooks.
The most likely documentation page a project author will read in
response to a policy warning is the page for the policy itself.
Add to every policy documentation page a note explicitly stating
that the OLD behavior is deprecated. Also mention this in the
cmake_policy() command documentation that explains how to set a
policy to OLD.
Suggested-by: Fraser Hutchison <fraser.hutchison@gmail.com>
Revert commit v3.3.0-rc1~435^2 (Windows-GNU: Do not tell find_library to
treat '.dll' as linkable, 2015-02-18). MinGW tools support linking to
'.dll' files directly and many non-CMake build systems still do not
provide a separate '.dll.a' file.
When documenting in the COMMAND option how to reference an executable,
we previously only explicitly covered how to do it for argv[0] and left
it to the reader to follow the reference to the generator expressions
manual. Add explicit mention of the TARGET_FILE genex in this
documentation since it will be a commonly used generator expression in
this context.
The test for this variable was removed in commit v2.8.8~330^2~7 (complex:
Remove ancient unused ComplexRelativePaths test, 2011-12-23).
Commit v3.1.0-rc1~425^2~2 (backtrace: Convert to local paths in
IssueMessage, 2014-03-12) appears to have accidentally made some backtraces
print relative paths with the variable because conversions which used to be
done at configure time, before the variable had an effect are now potentially
done at generate time.
The documentation of the variable says not to use it, and the docs are wrong in
that the variable actually applies in per-directory scope.
The read of the variable makes it harder to split conversion methods from
cmLocalGenerator where they don't belong. Remove it now.
Add section headers similar to the 3.2 release notes and move each
individual bullet into an appropriate section. Revise and consolidate
some bullets covering related areas.
Move all development release notes into a new version-specific document:
tail -q -n +3 Help/release/dev/* > Help/release/3.3.rst
git rm -- Help/release/dev/*
except the sample topic:
git checkout HEAD -- Help/release/dev/0-sample-topic.rst
Reference the new document from the release notes index document.
Add a title and intro sentence to the new document by hand.
CMake-generated targets are not supported by add_dependencies. State
this explicitly and use 'install' as an example since this may be
commonly attempted.
target_link_libraries() is being used in the example code but
target_include_directories() was probably meant to be used. The sentence
that starts with "Consuming code then" indicates that the example is
about using the appropriate include directory.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN were first
merged in commit v2.8.12~322 (Merge topic 'VISIBILITY_PRESET-property',
2013-06-05) but worked only for shared libraries and executables with
exports. Prior to commit v3.0.0-rc1~581^2 (GenerateExportHeader:
Deprecate add_compiler_export_flags function., 2013-09-02) the
add_compiler_export_flags function was used to add visibility flags to
all targets.
The visibility flags are useful for sources in all target types because
they may be later linked into shared libraries or executables with
exports. Introduce policy CMP0063 to enable them for all target types
while preserving compatibility with existing projects that do not expect
this.
Add an ExternalData_NO_SYMLINKS to enable use of copies instead of
symlinks to populate the real data files behind a DATA{} reference.
This will be useful on UNIX-like systems when the underlying filesystem
does not actually support symbolic links.
Suggested-by: Matt McCormick <matt.mccormick@kitware.com>
This reverts commit f85db2f323.
Discussion by the QtCreator community at
https://bugreports.qt.io/browse/QTCREATORBUG-13695
raises concerns about this particular approach to working with CMake
projects using QtCreator. Also, the functionality and design of the QBS
extra generator was never discussed on the CMake mailing list or with
QtCreator developers. There may be better ways to make the two tools
work together.
In order to avoid committing to long-term support of this generator
prior to such discussion taking place, revert it from CMake for now.
We may restore this or use an alternative design based on results of
such discussion.
e462ef74 Help: Add notes for topic 'cmake-gui-osx-install-command-line'
8ea2db26 cmake-gui: Replace command-line install dialog with information box
438ce4a0 cmake-gui: Add --install option to add command-line tools on OS X
41477d5c cmake-gui: Drop undocumented and unused --mac-install option
Brad King
Zack Galbreath
Erik Sjölund
Bill Hoffman
Michael Scott
Stephen Kelly