Support use-cases when the build dir is outside of root project dir.
Many projects set up output dir as <root_project>/../out/<project_name>/build
to be able to clean build dir more easily. This commit adds support
to build history file detection and it tries to find build history
files for artifacts that are:
- under root project dir (a default structure)
- under root project's build dir parent (to support typical custom setup)
Fixes https://youtrack.jetbrains.com/issue/KT-40875
Test: BaseIncrementalCompilationMultiProjectIT
Except when:
- the Gradle version is less than 6.0, it doesn't read the metadata
published by a newer Gradle by default.
- the requested dependency version is less than 1.5, because it doesn't
have metadata published.
Update integration tests to use kotlin-test common dependency.
KT-40225
When they are used explicitly in common source sets, they cannot be
resolved in platform ones after that since they only have
common kotlin-api variants in their metadata.
KT-40225
To do that, extract parts of publishing setup into reusable functions.
This change makes signing and repository configuration applied to all
project publications, not just to the Main one.
Also:
- Get rid of dependencies from non-default variants in the root pom
- Add an empty javadoc jar
KT-40225
Now that the default JVM target is 1.8, we have to add the JVM target
1.6 explicitly if the Android project is configured with source/target
1.6, and not do anything if it's configured with 1.8.
#KT-31027
Use `@Classpath` for kotlin stdlib input property. This is to
allow cache hits when builds are running on different machines
and path to kotlin stdlib differs.
Test: BuildCacheRelocationIT
[Gradle, JS] Fix tests for incremental compilation of IR klib dir
[Gradle, JS] Add hack of outputFile into kotlin2js plugin
[Gradle, JS] Remove producing klib-dir
[Gradle, JS] Try to fix outputFileOrNull in JS compile
Because on clean run, file is not yet created, isFile check is incorrect
Currently, KaptGenerateStubsTask may not generate KDoc comments
correctly. See KT-43593 for more details.
This commit provides a Kapt flag called
`kapt.keep.kdoc.comments.in.stubs`
to control whether KDoc comments will be included in the generated
stubs.
This flag is currently enabled by default to keep the existing behavior
and avoid breaking existing users.
Users who don't need KDoc comments in stubs but are hitting KT-43593 can
disable the flag.
Whether this flag will be disabled by default later is to be determined.
Bug: https://youtrack.jetbrains.com/issue/KT-43593
(Note that this commit only provides a workaround, it doesn't
actually fix the bug.)
Test: (Ir)ClassFileToSourceStubConverterTestGenerated#testCommentsRemoved
* Avoid resolving deprecated configurations in tests
This PR enables more integration tests run with warning-mode=fail by
updating "resolveAllConfigurations" task in a way where we don't resolve
deprecated configurations and instead check dependencies on alternative
configurations.
* Add custom resolvable configuration for testing
This leads to clearer error messages in Gradle variant-aware dependency
resolution failures. Gradle has deprecated those configurations since
long ago, and we didn't see much use of them as variant-aware dependency
resolution entities either.
So this commits sets `canBeConsumed` to false on these configuratons:
* compile (+ testCompile, fooCompile in MPP)
* runtime (+ testRuntime, fooRuntime, ...)
* compileOnly (+ testCompileOnly, fooCompileOnly, ...)
This change replaces the PR #3995
Fixed by outlining JS code that uses Kotlin variables making usages of
these locals explicit and preventing bugs due to one-sided variable renaming.
This prevents using Kotlin variables as lvalue in JS code.
This leads to cleaner error messages in Gradle variant-aware dependency
resolution failures. Gradle has deprecated those configurations since
long ago, and we didn't see much use of them as variant-aware dependency
resolution entities either.
So this commits sets `canBeConsumed` to false on these configuratons:
* compile (+ testCompile, fooCompile in MPP)
* runtime (+ testRuntime, fooRuntime, ...)
* compileOnly (+ testCompileOnly, fooCompileOnly, ...)
* default (+ fooDefault in MPP)
This change replaces the PR #3995
When dependencies are added to our corresponding configurations,
report errors, as there's no proper way to add those dependencies.
Issue #KT-43944 Fixed
Exclude modules where there are still warnings in an explicitly declared
variable `tasksWithWarnings`.
Also remove "-progressive" from compiler arguments in modules which are
built with non-latest language version, as the warning about that leads
to an error with -Werror.
Alexander Udalov