Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add a tooling model that provides the main C++ component and test suite of a particular Gradle project.

Moved the C++ tooling model builders into their own project separate from `language-native`.

  1. … 12 more files in changeset.
Start to wire in the C++ tooling model, producing the `componentType` based on the plugins applied to the root project.

  1. … 5 more files in changeset.
Introduce a shared source processor cache

It shares the source processor cache between compile tasks to reuse the

result if the include files resolve to the same location.

  1. … 13 more files in changeset.
Moved a couple of services from `testingNative` down to `platformNative`

  1. … 11 more files in changeset.
Added a factory for plugins to use to create native component instances. This currently is internal but may later move to the public API.

Using the factory decouples the plugins from the services used by the component implementations.

  1. … 9 more files in changeset.
Fixing tests

Signed-off-by: Daniel Lacasse <daniel@gradle.com>

  1. … 31 more files in changeset.
Use tool chain selector service in C++ base plugin

Signed-off-by: Daniel Lacasse <daniel@gradle.com>

  1. … 6 more files in changeset.
Introduce tool chain selector for Swift

Signed-off-by: Daniel Lacasse <daniel@gradle.com>

  1. … 3 more files in changeset.
Moved the some `FileCollection` implementations for efficiently handling task file inputs out of the native plugins and behind the `TaskFileVarFactory` service, where they can be reused, at least internally for now.

There are 2 implementations which are intended to be used for task input properties: a `ConfigurableFileCollection` that allows build logic to configure a bunch of input files, such as C/C++ source files, and a `FileCollection` that represents some task inputs that are calculated from other inputs, such as the headers of a C/C++ compile task. Both implementations do some in-memory caching during task execution to make snapshotting and task action execution faster.

Improved the implementations a little and added some unit test coverage. The implementations could be further improved, reused in a bunch more places and better integrated into input file snapshotting. This change does just enough so they can be used in the native compile tasks need.

  1. … 14 more files in changeset.
Moved parsing of C/C++ source files behind a build scoped service that takes care of caching in memory and on the file system. This change means that each source or header file is parsed once only, rather than once per depend and compile task.

  1. … 11 more files in changeset.
Changed C++ plugins to handle linking against a library from a Maven repository on Windows.

  1. … 8 more files in changeset.
Regroup bundle creation code in `SwiftBasePlugin`

  1. … 26 more files in changeset.
Don't apply the incremental source file analysis to Swift source files, as they don't have header files and all source files need to be compiled together. Incremental compilation will be implemented later.

This change fixes an issue where compilation would fail when some, but not all, source files of a project has changed since last compilation.

  1. … 6 more files in changeset.
Introduce a ExecutionScopeServices between BuildSession and Build scopes

- This isn't wired into anything, so no services actually work yet.

  1. … 30 more files in changeset.
Add @Override where missing in production software model sources

Prior to this change, the affected submodules had 2044 occurrences of

the @Override annotation. With this commit, there are now 3492

occurrences. This suggests some divergence in IDE settings, either

across developers, across time, or both. At the moment, it appears that

IDEA (15 CE) is configured correctly to add @Override automatically.

This same refactoring should probably be done globally acrosse the

Gradle codebase, but has been constrained here to software model-related

submodules (a) because it is what the author is responsible for and (b)

because significant refactoring of type hierarchies is underway there

right now--the kind of work most likely to benefit from the compiler

checks that proper use of @Override affords.

Should this same refactoring be applied globally, it would be worth

looking into enforcing consistent use of @Override via checkstyle or

similar at the same time.

  1. … 419 more files in changeset.
Adding build session scope to PluginServiceRegistry

+review REVIEW-5510

  1. … 34 more files in changeset.
Extract creation of compilation state cache from IncrementalNativeCompiler to a gradle scoped factory service to avoid multiple creations of the cache which resulted in a file handle leak.

+review REVIEW-5440

  1. … 29 more files in changeset.
Renamed org.gradle.language.nativebase -> org.gradle.language.nativeplatform

    • -0
    • +33
    ./NativeLanguageServices.java
  1. … 90 more files in changeset.