All Gradle specific kpm entities shall be disambiguated by using
the `GradleKpm` prefix. For example `MyEntity` shall now be called
`GradleKpmMyEntity` and a subclass would be called like
`GradleKpmSpecialMyEntity`
* KotlinExecution
* KotlinExecutionSource
* KotlinTestRun
* Aggregating executions and execution sources
* KotlinTargetWithTests
* Add a `testableTargets` extension
* Make some Kotlin/Native targets testable (this requires
having a separate preset type for them)
* Implement test runs encapsulating the tests for all
existing testable targets by refactoring their
TargetConfigurator classes
Issue #KT-32679 Fixed
Earlier native tests were represented by the same binary type as product
executables. We also used to create test tasks in the same manner as run
tasks for product executables. Such tasks could be obtained used a property
of an executable binary with type Exec.
But now we have a separate class for test tasks. Also we probably will want
to create several tasks for the same test. So we cannot use the same run task
property for both test and product executables. Also representing test and
product executables by the same binary type leads to the fact that assemble
task execution causes building not only product binaries but also the test
ones.
This patch solves the issues described above by introducing a separate binary
type for tests. Such a test binary can be created in the same manner as other
binaries:
kotlin.macosX64 {
binaries {
test("integration") { ... }
}
}
One test binary and a task executing it is created by the plugin out of the box.
This test binary replaces a test executable used to be created earlier.
Issue #KT-31609 Fixed
Deprecate the `jvmWithJava` preset, add warning.
Add a function `withJava()` to JVM MPP targets which applies the 'java'
plugin and sets up the Kotlin & Java interoperation.
Issue #KT-26256 Fixed
Signed-off-by: Sergey Igushkin <hotkeytlt@gmail.com>
The kotlin-native-shared artifact includes API allowing
us to work with K/N platforms, hosts, distribution etc.
This patch replaces a dependency on kotlin-native-utils
containing copies of such classes with a dependency on
published kotlin-native-shared in the Gradle plugin and
bundles kotlin-native-shared into the Gradle plugin jar.
In 1.3.0 only basic settings for final native binaries (e.g.
executables or frameworks) are available. They allow a user to
specify what kinds of binaries should be produced from one or another
compilation but they don't allow specifying different options for
different binaries or creating more than 2 (debug and release)
binaries of the same kind (e.g. executable) from the same
compilation. Also link tasks for these binaries are created after
project evaluation thus they are inaccessible for a user outside
of an afterEvaluate block.
This patch adds an extended binary DSL allowing a user to declare
binaries independently from compilations and to specify different
options (e.g. linker arguments) for different binaries. Also
link tasks for binaries declared in this DSL are created at a
configuration time so user can access them outside of an
afterEvaluate block.
Also this patch adds creating run tasks for all executables
declared in the buildscript (KT-28106)
Initial DSL methods for binaries declaration are still supported.
Kotlin DSL example is the following:
kotlin {
macosX64 {
binaries {
// Create debug and release executable with
// a name prefix 'Foo'.
// Two domain objects will be created:
// fooDebugExecutable and fooReleaseExecutable
executable("Foo", listOf(RELEASE, DEBUG)) {
compilation = compilations["foo"]
entryPoint = "foo.main"
linkerOpts.add("-Llib/path")
println(runTask.name)
}
// Name prefix and build types are optional.
// debugFramework and releaseFramework are created here.
framework()
}
}
}
As Gradle Groovy DSL does out-of-the box not allow working with
SAM-receiving functions in the same way as those accepting a Closure,
and, moreover, does not work with Kotlin default parameters, we need
to provide Groovy-friendly DSL functions along with Kotlin DSL functions
This commit adds those additional members for all of the newly
introduced MPP DSL members.
* Pull the `targets` and `presets` properties of the `kotlin` extension
up to an interface in `kotlin-gradle-plugin-api`
* Generate the code: we need type-safe statically-typed functions for
different target type, which seems to be only possible to achieve by
providing a function per preset.
* Place these functions in the top-level `kotlin` Gradle extension,
rather than extension functions for `kotlin.targets`:
- `kotlin.jvm { ... }` will work, while `kotlin.targets.jvm { ... }`
won't, the extension function needs to be somehow brought into scope
- reducing the nesting level by one seems to be a good move here
Issue #KT-26389 Fixed
Stanislav Erokhin