This patch adds a group of shortcut DSL methods allowing a user to
create simulator and device targets for Apple platforms along with
corresponding common source set(s) in one command. iOS, tvOS and
watchOS targets are supported.
Issue #KT-33856 fixed
As associated compilations will see internals of each other, they now
need to share the module name for the compiler to be able to correctly
generate calls to the internals.
Move `moduleName` to `KotlinCompilation`.
Group associate compilations into modules in a DSU-like way, use a
single module name for all of the compilations grouped into a module.
Add non-public API for the IDE to query additional visible source sets
for each source set.
Implement visibility inference via associate compilation links.
Implement visibility requirements for source sets and requirements
satisfaction checks in Gradle build.
Partial implementation of the associate compilations proposal. A
compilation can now contain links to other compilation that it compiles
against. This links will replace ad-hoc inter-compilation dependencies.
Issue #KT-34009 Fixed
* 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
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 Gradle 5.3, there was a change to the internal logic of publishing
`SoftwareComponent`s with the 'maven-publish' plugin, and,
simultaneously, a new public API was introduced for user-defined
software components, see https://github.com/gradle/gradle/pull/8399
Earlier, the 'maven-publish' plugin used the Gradle `Usage` attribute
values to arrange the dependencies of a software component's
`UsageContext`s into the Maven scopes. Now that mechanism doesn't work
and a `SoftwareComponent` must provide an explicit mapping of the
variants to POMs by using the `SoftwareComponentFactory.adhoc` API.
However, the new API lacks some features we need to properly publish an
MPP, such as adding a component to another one as a variant, so we still
create old-style software components under the hood and
then wrap them into the new API (and then wrap the adhoc components once
again).
We also continue to use the old-style components for Kotlin-specific
logic like finding a target in another project that a dependency
resolved to, as the components produced by the new API lack crucial
information that is used in the logic, like references to
`KotlinCompilation`s.
Issue #KT-30379 Fixed
With gradle > 5.0 `publish()` helper call should be done before
`noDefaultJar()` or any other artifact hacks, otherwise singing plugin doesn't sign any jars
* Move source artifacts to KotlinVariant classes (since joint Android
variants may have multiple source artifacts, make it a set)
* Change lowerSpinalCaseName to dashSeparatedName (doesn't transform
the strings to lower case inside)
* Don't transform the project name to lower case (in the future, it may
be reasonable to stop transforming the target and component names, too)
Still transform the target names and the component names.
Currently, this is the way we don't break existing publications and may
still reconsider this in the future.
* Add a workaround for a list of GString's assigned to
publishLibraryVariants
* Check for Android library variants existence in a more strict way,
report existing variants that are not library variants.
As KotlinCompilation only contains the directly added source sets in its
`kotlinSourceSets` property, we need to provide a convenient way to
collect the whole source sets hierarchy for a compilation.
We added internal `allKotlinSourceSets` some time ago, and it seems
reasonable to expose it as public API.
Issue #KT-28749 Fixed
Instead of exposing a single `component` in a target, allow it to have a
set of `components`, then create a Maven publication for each of the
components.
Move `createUsageContexts` to private API since a target that has
multiple publications may need to create the usage contexts for those
publications differently.
Move some of the components technical stuff to interfaces
`DelegatedToPublication` and
`ComponentWithCoordinatesDelegatedToPublication` in order to reuse it
later for Android's components.
Make compiler plugin options evaluate lazily, with Lazy<String> and
FileCollection as replacements for the eagerly-evaluated data.
Adjust compiler plugin option usages so that their evaluation is not
triggered when not necessary.
Issue #KT-26065 Fixed
Gradle has a function `attributes { ... }` for `Configuration`, so we
can introduce one, too, for uniformity of the DSLs. This will configure
the `val attributes: AttributeContainer` of the `KotlinTarget` and
`KotlinCompilation`.
Issue #KT-27682 Fixed
* Add DSL for project(...) with path and configuration
* Add DSL for e.g. api(someDependency) { /* ... */ }
* Add DSL for e.g. api(kotlin("stdlib"))
Issue #KT-26663 Fixed
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.
Previously, the connection between a `KotlinCompilation` and its
default `KotlinSourceSet` (the one automatically created and added into
the compilation) was not expressed in the MPP model in any reasonable
way that can be used in the build scripts.
However, this connection seems to have settled in the build logic, and
it may be useful to be able to get the default source set from a
compilation, for example, to be able to configure dependencies across
several targets in a uniform way.
The metadata compilations don't have their dedicated source sets, but
we can think of commonMain as a default source set for the project's
metadata, is it is currently in fact only contains the declarations from
commonMain.
Issue #KT-27685 Fixed
To simplify configuring a `KotlinCompilation` with Gradle Kotlin DSL, it
is essential to expose statically-known types where possible.
This commit parametrizes `KotlinCompilation` with its Kotlin options
type (a subtype of `KotlinCommonOptions`) and adds `kotlinOptions` and
`compileKotlinTask` to `KotlinCompilation`.
(minor) Also reduce the visibility of `attachClassesDir` and
`setupPlugins` to internal, since this API is not for external use.
This new interface uses a more general type for its kotlinOptions,
KotlinCommonToolOptions rather than KotlinCommonOptions. This is
needed for the Kotlin/Native task to implement a common interface
with the other Kotlin compilation tasks.
* 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
Add the corresponding Gradle plugin DSL, consistency checks, and logic
for propagating these settings to the compiler during build.
Issue #KT-26840 In Progress
Remove the implementation of the `FileCollectionInternal` interface in
`KotlinCompilationOutput`. This interface may change unexpectedly (and
does between Gradle 4.10 and 5.0) so we need to get rid of its
implementation.
On the other hand, we can't just implement `FileCollection` instead
because Gradle internally assumes that all `FileCollection` instances
are also `FileCollectionInternal`. So the way to fix this is to remove
`SourceSetOutput` from superinterfaces of `KotlinCompilationOutput`
altogether.
Instead, to work with `SourceSetOutput` and `KotlinCompilationOutput`
in a uniform way, provide a wrapper for `SourceSetOutput`:
`KotlinWithJavaCompilationOutput` that is basically a proxy
class.
* To avoid unexpected effects from the Gradle instantiation mechanisms
for attribute values, use a safer String attribute type for the
KotlinPlatformType attribute
* Rename its entries to keep enum entries naming consistent
When a Kotlin metadata input configuration tries to resolve a module
with no Kotlin metadata (such as: plain old Maven module, a non-MPP
Kotlin project with a single platform), it should be able to resolve
successfully.
Given that the input metadata configurations extend from source set
dependencies configurations, where platform-specific dependencies may
occur, allowing the metadata configuration to resolve such dependencies
into platform artifacts seems to achieve successful dependency
resolution.
Issue #KT-26834 Fixed
Kotlin/JVM and Kotlin/JS use shaded compiler, but
Kotlin/Native uses non-shaded one.
Serialization plugin was configured to use either shaded or non-shaded
plugin version, because we used one configuration for resolving
compiler plugins.
This change introduces 'kotlinNativeCompilerPluginClasspath' configuration
for resolving Kotlin/Native compiler plugins.
In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed
* Add dependency on KN shared in gradle-plugin
* Basic support for Kotlin/Native:
* Target presets
* Compilation into a klib
* Compilation into native binraies: framework and executable
* Basic dependencies between projects
* No jars in native publications
* Replace '-' with '_' in framework names
* Escape quotes in native command lines on Windows
* Move targets from Kotlin/Native repo
* Download KN compiler using Gradle's mechanisms
* Support source set dependencies in native
Alexander Udalov