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
Use it to split pipe and stdin/out handling out of cmServer itself.
The server will shut down when it looses its connection to the client.
This has the nice property that a crashing client will cause the server
to terminate as the OS will close the connection on behave of the client.
adf1e32f Help: Add notes for topic 'ctest-capture-error'
d328dc68 CTest: Add CAPTURE_CMAKE_ERROR val to `ctest_*` commands
9ac2e189 ctest_coverage: If gcov is not found just warn, not error
501f9c93 cmGlobalNinjaGenerator: Add API to check for implicit outputs support
144a24dc cmGlobalNinjaGenerator: Teach WriteBuild about implicit outputs
Enable the server to support development with some helper tools:
You can now request debug information with statistics on how
long execution of a command took, how long it took to serialize
the JSON files, and how big the serialized JSON string is.
Also allow to dump results into a file.
Add new test properties:
* FIXTURES_SETUP
* FIXTURES_CLEANUP
* FIXTURES_REQUIRED
to specify the roles and dependencies of tests providing/using
test fixtures.
If a `ctest_*` command has CAPTURE_CMAKE_ERROR then any errors generated
by cmake during that command will cause the value to be assigned `-1`.
This will prevent a `ctest -S` script from returning non-zero unless the
script explicitly calls `message(FATAL_ERROR)`.
Fortran 2008 [1] adds support for a new syntax related to modules:
submodule ( ParentModule ) SubModule
submodule ( ParentModule : SubModule ) NestedSubModule
Both of these mean that the current source file requires the module
`ParentModule` to be available if it is not provided in the current
file. Teach our Fortran dependency scanner to parse this syntax to
extract this relationship. For now simply tolerate the nested submodule
case and extract only the dependency it expresses on the main module.
Further work will be needed to extract dependencies among nested
submodules.
[1] http://fortranwiki.org/fortran/show/Fortran+2008Closes: #16234
Fortran allows the syntax
MODULE PROCEDURE ...
MODULE FUNCTION ...
MODULE SUBROUTINE ...
to declare procedures/functions/subroutines that are members of modules.
Do not treat such syntax as the definition of a module with one of these
names.
Issue: #16234
Ninja 1.7 introduced support for implicit outputs on build statements.
Add an internal API to check whether the Ninja version in use for the
build supports this feature.
Ninja 1.7 introduced support for implicit outputs on build statements.
Teach WriteBuild to generate the corresponding syntax. Leave it up to
callers to decide whether implicit outputs are supported by the Ninja
version in use. For now simply update all call sites to pass an empty
list of implicit outputs.
Our buildsystem model says that the default Fortran module output
directory is the build tree directory corresponding to the source tree
`CMakeLists.txt` file adding the current target. Extend
`cmGeneratorTarget::GetFortranModuleDirectory` to allow generators to
pass in the compiler working directory. If the working directory does
not match the default Fortran module output directory then we need an
explicit module directory flag (e.g. `-J`) to tell the compiler to
put/use modules in the latter.
This does not affect the Makefile generator but will be useful for
future introduction of Fortran support to the Ninja generator.
d0be1e15 Add directory properties to get source and binary directories
cbca6582 Add directory property to list buildsystem targets
7a4b8d0d Add a directory property to list subdirectories
089868a2 cmState: Record buildsystem target names in each directory
6429d6d9 cmOutputConverter: Remove now-obsolete Convert method
ad790617 Convert: Inline uses of START_OUTPUT
4cf707b0 Convert: Remove HOME_OUTPUT enum value
3d12ffbf Ninja: Update comment variable reference
4d69ac76 Convert: Move access to BinaryDirectory out of loops
e7c89567 Convert: Inline uses of HOME_OUTPUT
dc510919 Common: Use a string instead of enum for WorkingDirectory
76833149 Convert: Simplify switch
dc95020e Convert: Remove obsolete MAKERULE enum value
1825f876 Convert: Move access to BinaryDirectory out of loops
25c39ac2 Convert: Inline HOME_OUTPUT MAKERULE conversion
516e79ba Convert: Inline MAKERULE conversions
e13e519e Convert: Move access to BinaryDirectory out of loops
34c6e995 Convert: Avoid HOME_OUTPUT enum when converting to relative paths
839c65bc Convert: Move access to CurrentBinaryDirectory out of loops
21b5fdf9 Convert: Avoid START_OUTPUT enum when converting to relative paths
...
Allow for experimental cmProtocolVersions, which will only ever get
listed if the server was started with the (undocumented)
"--experimental" flag.
Mark current protocol version 1.0 as experimental.
The enums just introduce unfamiliar names and don't provide value.
The order of arguments is reversed, as that is the result of the
cmOutputConverter::ConvertToRelativePath
overload which accepts the RelativeRoot enum.
Add SOURCE_DIR and BINARY_DIR directory properties that return the
absolute paths to the corresponding directories. These correspond
to the target properties of the same names that we already have.
Maintain in the directory state the list of target names added to be
built. These are normal, non-imported targets (but do include INTERFACE
libraries).
Enable the initial handshake of the client to complete the connection
to the server.
The handshake sets the protocol version that client and server will
use to talk to each other. The only way to change this is to quit the
server and start over.
CMake specific information is also set during the initial handshake.
Since cmake so far never had to change basic information about any project
while running, it was decided to keep this information static and
require a restart of the cmake server to change any of these.
Adds a bare-bones cmake-server implementation and makes it possible
to start that with "cmake -E server".
Communication happens via stdin/stdout for now.
Protocol is based on Json objects surrounded by magic strings
("[== CMake Server ==[" and "]== CMake Server ==]"), which simplifies
Json parsing significantly.
This patch also defines an interface used to implement different
versions of the protocol spoken by the server, but does not include
any protocol implementaiton.
3fab1fef cmNinjaNormalTargetGenerator: make sure comments match parameter names
7b94a7ad cmCommandArgumentsHelper: simplify boolean expression
782fcbb9 Use CM_NULLPTR
809ca6c8 Use braces around statements
516f8edb Avoid else after return
d9f5d3c5 Remove redundant get() call on smart pointer
3fda1094 Mark overridden functions with CM_OVERRIDE
I otherwise get:
Expected stderr to match:
expect-err> CMake Error at AppendNotOutput.cmake:1 \(add_custom_command\):
expect-err> add_custom_command given APPEND option with output.*
expect-err> which is not already a custom command output.
expect-err> Call Stack \(most recent call first\):
expect-err> CMakeLists.txt:3 \(include\)
Actual stderr:
actual-err> CMake Error at AppendNotOutput.cmake:1 (add_custom_command):
actual-err> add_custom_command given APPEND option with output
actual-err> "/home/stephen/dev/src/cmake/with
actual-err> space/Tests/RunCMake/add_custom_command/AppendNotOutput-build/out" which is
actual-err> not already a custom command output.
actual-err> Call Stack (most recent call first):
actual-err> CMakeLists.txt:3 (include)
Using a specific line for paths is a style already used elsewhere for
the same reason, such as CMP0041 output.
Split the ConvertToRelativePath funtion into ConvertToRelativePath and
ForceToRelativePath. Both functions take the local path as a string
rather than a vector of path segments. Reimplement the old interface on
top of the two new functions for interface compatibility.
9353d991 cmTarget: Remove unused support for partial construction
fa3897b2 cmGlobalGenerator: Refactor global target construction
916d8445 cmGlobalGenerator: Split CreateDefaultGlobalTargets implementation
Refactoring in commit v2.8.10~58^2~2 (Ninja: move -LIBPATH behind -link
option, 2012-09-26) added arguments to cmLocalGenerator::GetTargetFlags
and updated the call sites. However, in the cmake::FindPackage and
cmLocalGenerator::AddBuildTargetRule call sites it added the new
arguments in the wrong order. The latter was never used and has been
removed. The former remains buggy and prints out compiler flags instead
of the link framework/library search paths. Fix its argument order.
Avoid using partially-constructed cmTarget instances. Collect the
information about how to construct each target in a separate structure
and then actually create each cmTarget with full construction.
Ninja does not support PRE_INSTALL_SCRIPT properties and does not
perform the relink required by installation without help from some other
mechanism, so error out if it would be required.
Issue: #13934, #16304
Add `CMAKE_FIND_PACKAGE_SORT_{ORDER,DIRECTION}` variables to specify
sort order and direction.
When multiple package with the same name have been found in the same
location sorting option can be used to force a specific version to be
loaded (e.g. libA_1.12.0 instead of libA_1.1.0). Currently sorting by
NAME and by NATURAL order have been implemented.
Natural ordering makes use of the `strverscmp(3)` ordering.
7a2e114d cmTarget: Inline SetType method at only remaining call site
00e78c19 cmTarget: Construct with basic information up front
9d11bd50 Avoid requiring default cmTarget constructor for map indexing
d97513d8 cmTarget: Add method to get a copy adapted for a directory
The `std::map<>` index operator requires a default constructor on the
value type. Avoid requiring a default constructor on `cmTarget` just
for this purpose.