Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
89043267 server-mode: Add command to compute the build system
0a8ad670 server-mode: Add a configure command
544f65f4 server-mode: Set global configuration of cmake via a command
82104cc7 server-mode: Query global configuration of cmake via a command
Fortran INCLUDE statements are not handled by the preprocessor.
Since the location of the preprocessed file is distinct from the
original source file explicitly add the source file's directory
as an include path in the actual compile step (not the preprocessing step)
so INCLUDE can find it.
Closes: #16332
This method is used by directory get/set APIs. With the new
`SUBDIRECTORIES` and `BUILDSYSTEM_TARGETS` methods projects may now make
heavy use of these APIs to traverse their directory structure and
process targets. Make this faster by indexing the directory lookups.
Add a command to trigger cmake to configure a project.
Keep this separate from the compute step (added in the next commit)
to faciliate applications like cmake-gui.
Add "globalSettings" command that returns:
* Return capability information
* Return currently used generator/extra generator
* Return a range of flags for debug/trace/etc.
The basic codelite generator creates .project files based on the
`project()` stanza. Add a `CMAKE_CODELITE_USE_TARGETS` option to use
the targets instead.
Create a new CMAKE_Swift_LANGUAGE_VERSION variable to specify the
SWIFT_VERSION attribute in a generated Xcode project. Ideally this
would be a `<LANG>_STANDARD` property but since Swift support is
very minimal we should reserve that property for more complete
treatment later.
Issue: #16326
The `.pbxproj` file must now specify a `SWIFT_VERSION` value.
Set it to the legacy value of "2.3" for now. Later this can
be made configurable (e.g. to "3.0").
e22d30e2 server-mode: Allow for sending signals
cc576c2c server-mode: Pass server into cmServerProtocol
277ffa28 server-mode: Move constants for server mode into its own file
All Fortran sources need to be preprocessed before any source may be
compiled so that module dependencies can be (later) extracted. Factor
out an explicit preprocessing step preceding compilation. Use Ninja
depfile dependencies on the preprocessing step and then compile the
already-preprocessed source with a separate build statement that depends
explicitly only on the preprocessor output. Later we will insert
dynamic discovery of module dependencies between these steps.
Create an internal `cmake -E cmake_ninja_dyndep` tool to read the "ddi"
files generated by `cmake -E cmake_ninja_depends` from all sources in a
target and generate a ninja dyndep file that tells Ninja about Fortran
module dependencies within the target and on target dependencies.
Create an internal `cmake -E cmake_ninja_depends` tool to scan an
already-preprocessed Fortran translation unit for modules that it
provides or requires. Save the information in a "ddi" file with a
CMake-private format for intermediate dynamic dependency information.
This file may the be loaded by another tool to be added later.
Kitware maintains a branch of Ninja with support for dynamically
discovered dependencies (dyndep) that has not yet been accepted
upstream. Add an internal API to check whether the Ninja version in use
for the build supports this feature.
Delay rejection of Fortran until after we've determined the version of
the `ninja` tool to be used. This will later allow us to enable Fortran
support based on the version of ninja.
While at it, make the rejection an immediate fatal error. Also provide
a stack trace so readers know what code tried to enable Fortran.
Refactoring in commit v3.5.0-rc1~272^2~16 (cmGeneratorTarget: Add API for
property keys, 2015-10-25) changed the Xcode generator implementation of
`XCODE_ATTRIBUTE_...` properties to use the target `GetProperty` method on each
`XCODE_ATTRIBUTE_...` property listed by `GetPropertyKeys` instead of looping
over the property entries directly. This made the lookup of property names of
the form `XCODE_ATTRIBUTE_..._LOCATION` accidentally trigger the computed
property logic for the undocumented/legacy `<CONFIG>_LOCATION` property. Of
course the computed property value is not the same as the value stored in the
`XCODE_ATTRIBUTE_..._LOCATION` property. Fix the computed property logic to
avoid triggering on `XCODE_ATTRIBUTE_...` attributes.
Closes: #16319
Brad King
Nils Gladitz
Kitware Robot
Tobias Hunger
Minze Zwerver
Daniel Pfeifer
Roman Wüger
Clinton Stimpson