Android preset needs to be removed in favor of Android Pluggable Target
Changes were originally introduced by commit:
becf50ee0f
but then, unfortunately, reverted due to binary compatibility issues
^KT-59049 Verification Pending
^KT-57903 Verification Pending
This reverts commit becf50ee
These changes are binary incompatible due to move of methods with
default arguments.
^KT-59049 In Progress
^KT-57903 In Progress
Android preset functions were moved to a separate interface
because we need to write custom deprecation with ReplaceWith
due KT-57903.
After that we had generated:
- all the K/N preset functions
- jvm functions.
I decided to move jvm function to separate file too,
so the whole division to several files would be somewhat sane.
I kept the KotlinTargetContainerWithPresetFunctions interface to
keep source/binary compatibility for the `android`/ `jvm` preset
functions users
#KT-57903 In Progress
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()
}
}
}
Dmitry Savvinov