* Add a platform type androidJvm that is one-way compatible (can
consume but cannot be consumed) with jvm, register the matching
strategy
* Write our attributes to Android's output configurations (this uses
a naming convention that Android inherits from Java, but there's no
public API at the moment for that)
* Setup configurations' extendsFrom and inherit sources of source sets.
This make it unnecessary to restore transitive dependencies of a
source set at its use sites, since their sources and dependencies are
already included.
* Use dependsOn during default configuration instead of compilation.source()
* Parameterize with the target name and use it in the task names
* Get rid of separate task providers for common and js, use the default
with an appropriate target name
1. Kapt resolves runtime classpath during configuration, and because of
that we are unable to setup configurations that already took part in
dependency resolution. To fix that, run Kapt configuration as a separate
step out of the main loop over the variants
2. Old Android projects (< 3.0.0) don't have `api` and `implementation`
configurations. To stay compatible with those, ignore these
configurations being absent during configurations hierarchy setup.
Add default implementations for KotlinTarget and KotlinCompilation
(some of them are used in code added by further commits).
Refactor AbstractKotlinPlugin so that parts of its logic can be easily
applied outside the plugin (needed for MPP plugin later).
The single platform Kotlin plugins having Kotlin compiled along with
Java will now create a KotlinCompilation and a KotlinSourceSet per Java
source set or per Android variant.
The build configuration logic will use KotlinCompilation
objects rather than Java or Android plugin entities.
Subplugins API and implementations are updated to use KotlinCompilation.
(Note: this commit leaves the repository in a non-compilable state as it
leaves some of the old API usages unchanged; they are replaced with new
implementations in further commits where more appropriate)
The new implementation covers the wider interface, and the factory
should now be used not on its own but in a named domain object container
(the API for creating a source set is now provided through the
source sets container rather than the factory, so that source sets are
also properly registered).
Do not call this method the second time in KotlinToJVMBytecodeCompiler
where all KtFile instances are already created; just get only those
files that are in the needed module, which can be determined solely by
the file path.
Also "kotlinize" getKtFiles and rename to createKtFiles
Otherwise the "outputDir" in these tests was treated as relative to the
project root, and starting from 63b4302cea, running these tests resulted
in the "whatever" directory being created in the project root
To be able to use it correctly inside an xml build file where, if the
path is not absolute, it's treated as relative to the build file path
(which is TMP_DIR in several tests of the subsequent commit)
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
Denis Zharkov