| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
b941f3bf CTest::CompressString: Avoid manual delete
a5a7771a CTest::CompressString: Reorder code to avoid unnecessary allocation
6ed56457 CTest::Base64EncodeFile: Avoid manual delete
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
b35568f3 Xcode: Add option to set Swift language version
49d50ad4 Xcode: Port rudimentary Swift support to Xcode 8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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").
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
33058150 Help: Document Ninja generator conditional Fortran support
59aae292 Ninja: Add dyndep rules for Fortran module dependencies
39ebfc79 Ninja: Add explicit preprocessing step for Fortran
9a77680e Ninja: Conditionally allow Fortran based on ninja 'dyndep' support
0f331d78 Ninja: Add internal tool to produce a ninja dyndep file for Fortran
d3e0b64b Ninja: Add internal tool to scan Fortran code for module dependencies
8eca59a1 Ninja: Add comment with Fortran dependency design documentation
a57d1bb7 Ninja: Add API to check for dyndep support
0488ae63 Ninja: Refactor ninja feature detection
f0a23aa3 Ninja: Refactor Fortran rejection logic
|
| |
| |
| |
| |
| | |
Teach the Ninja generator to add dyndep rules and bindings as described
in the design comment in `Source/cmGlobalNinjaGenerator.cxx`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Detect from the version of Ninja whether it supports the dynamically
discovered dependencies (dyndep) feature needed to support Fortran.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Check for features as soon as we know the ninja version. Save the
results so we do not have to re-compare versions every time.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | | |
764775c4 Fix XCODE_ATTRIBUTE_..._LOCATION target property lookup
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Enable the server to send signals.
|
| | |
| | |
| | |
| | | |
The information will be needed to send signals.
|
| |/
| |
| |
| |
| | |
This removes some duplication and makes it easier to reuse the
vocabulary.
|
|\ \
| | |
| | |
| | |
| | | |
48624b3c cmake-gui: Do not remove library paths for Qt5 plugins.
|
| | |
| | |
| | |
| | |
| | | |
Not removing library paths is necessary for QFileDialog to function correctly
on Linux when using Qt5.
|
| | | |
|
| |\ \ |
|
| |\ \ \ |
|
| |\ \ \ \ |
|
| |\ \ \ \ \ |
|
| |_|_|_|_|/
|/| | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
73f47c9e CTest: Add support for test fixtures
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add new test properties:
* FIXTURES_SETUP
* FIXTURES_CLEANUP
* FIXTURES_REQUIRED
to specify the roles and dependencies of tests providing/using
test fixtures.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
1d601c6c server-mode: Introduce cmServerConnection
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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)`.
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
4fb2b41a server-mode: Add debug support
537efe05 server-mode: Report Messages from cmake to clients
ca779948 server-mode: Automate progress reporting
70b8ba9a cmake-server: Use consistent constant naming style
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Pass messages sent from cmake via Error(...) or Message(...) on
to clients.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Wire up cmake::SetProgressUpdate to do progress reporting via the
cmake server.
|
| | |/ / / / / /
| |/| | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
df4aeb31 Help: Add notes for topic 'fortran-submodules'
b5ac8b8a Fortran: Add support for submodule syntax in dependency scanning
bdcc1f51 cmFortranParser: Skip module procedures/functions/subroutines
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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+2008
Closes: #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
|