Currently, the performance overhead when loading a Gradle property
consists of:
1. Creating a Provider
2. Resolving the Provider
Both steps are performed even when the same property was loaded before.
That means this overhead will multiply when there are a large number of
property read requests (e.g., in KT-62496, the tested project 400,000
read requests for only 17 properties).
To improve performance, we will now cache both steps with a
BuildService.
With this commit, configuration time for the tested project returns to
the same level before commit d6becee where the performance regression
happened (that commit can't be reverted because it introduced
`Provider`s which are required for proper Gradle usage).
Test: Manually verified on the large project in KT-62496
^KT-62496 Fixed
It is not obvious from 'KotlinSingleTargetExtension' that calling
into 'target' is unsafe and it might throw.
Ordering code (especially with Android) is hard:
It is not clear when the target will become available.
The Future (and forAllTargets implementation) is intended
to make working with targets generically more safe.
KT-61634
And read commonized klibs in execution time only.
it is possible only when rootOutputDirectoryProperty is marked as
OutputDirectory.
```kotlin
class Producer {
@get:OutputDirectory
val foo: RegularFileProperty
@get:Internal
val bar: RegularFileProperty
}
val foo = producer.flatMap { it.foo.map { it.listFiles() } }
val bar = producer.flatMap { it.bar.map { it.listFiles() } }
```
`foo` file collection will be evaluated at execution time.
Because `Producer.foo` is an OutputDirectory and its content unknown
during configuration time.
But `bar` file collection will be evaluated at configuration time.
Because according to gradle model it is not Output and therefore
its content can be evaluated before task execution.
^KT-61359 Verification Pending
It should be possible to commonize native distribution from clean state
and compile shared native code in the same gradle build with enabled
configuration cache.
^KT-61359 In Progress
Gradle doesn't track removed files in OutputDirectory after task
execution. So if task removed some files and if these files
are added back the task would be still UP-TO-DATE. Which is incorrect.
Executing clean task on empty directory is the same as check that
directory is empty. Therefore, this up-to-date check can be removed.
^KT-62611 Verification Pending
This change is intended to improve the intuition of developers.
After adding the two functions, many times developers (me) have
tried to use the 'wrong' (which is now the new name) function name.
KT-61634
Ilya Goncharov