[Native] Simplify filtering of deserialized KLIBs on 2nd stage The KLIB resolver may load a huge number of libraries on the 2nd Kotlin/Native compilation stage. This not only includes the libraries explicitly specified in compiler's CLI, which is expected, but also the ones implicitly loaded from the distribution. Sometimes, there might be 100+ platform libraries among them (example: any Apple target). Not all of them should necessarily be included in the expensive IR linkage process and the pipeline of lowerings. That's the reason there is a special filtering of "roots" in `NativeSecondStageCompilationConfig.librariesWithDependencies()`, which helps to narrow down the set of processed libraries to only the required ones. It turns out that one part of the filtering condition is useless and can be safely removed along with the corresponding Klib flag: - The `Klib.hasDeclarationsAccessedDuringFrontendResolve` flag is only raised when a `KlibMetadataDeserializedPackageFragment` is touched. - `KlibMetadataDeserializedPackageFragment` is touched only when few K1-based checkers are executed. This happens just because the K1 frontend is still used in the Kotlin/Native driver to initiate the backend compilation pipeline. - The checkers explore only the "included" library (-Xinclude) and the standard library. So, the flag can be raised only for a few libraries and in practice can't be reliably used to distinguish the required libraries. ^KT-83940
Welcome to Kotlin!
Kotlin is a concise multiplatform language developed by JetBrains and contributors.
Some handy links:
Support for multiplatform programming is one of Kotlin’s key benefits. It reduces time spent writing and maintaining the same code for different platforms while retaining the flexibility and benefits of native programming.
This repository is using Gradle toolchains feature to select and auto-provision required JDKs from Eclipse Adoptium project.
Alternatively, it is still possible to only provide required JDKs via environment variables (see gradle.properties for supported variable names). To ensure Gradle uses only JDKs from environmental variables - disable Gradle toolchain auto-detection by passing -Porg.gradle.java.installations.auto-detect=false option (or put it into $GRADLE_USER_HOME/gradle.properties).
On Windows you might need to add long paths setting to the repo:
git config core.longpaths true
The project is built with Gradle. Run Gradle to build the project and to run the tests using the following command on Unix/macOS:
./gradlew <tasks-and-options>
or the following command on Windows:
gradlew <tasks-and-options>
On the first project configuration gradle will download and setup the dependencies on:
intellij-core is a part of command line compiler and contains only necessary APIs.idea-full is a full blown IntelliJ IDEA Community Edition to be used in the plugin module.These dependencies are quite large, so depending on the quality of your internet connection you might face timeouts getting them. In this case, you can increase timeout by specifying the following command line parameters on the first run:
./gradlew -Dhttp.socketTimeout=60000 -Dhttp.connectionTimeout=60000
clean - clean build resultsdist - assembles the compiler distribution into dist/kotlinc/ folderinstall - build and install all public artifacts into local maven repositorycoreLibsTest - build and run stdlib, reflect and kotlin-test testsgradlePluginTest - build and run gradle plugin testscompilerTest - build and run all compiler testsTo reproduce TeamCity build use -Pteamcity=true flag. Local builds don't run proguard and have jar compression disabled by default.
OPTIONAL: Some artifacts, mainly Maven plugin ones, are built separately with Maven. Refer to libraries/ReadMe.md for details.
To build Kotlin/Native, see kotlin-native/README.md.
It is recommended to use the latest released version of Intellij IDEA (Community or Ultimate Edition). You can download IntelliJ IDEA here.
After cloning the project, import the project in IntelliJ by choosing the project directory in the Open project dialog.
For handy work with compiler tests it's recommended to use Kotlin Compiler Test Helper.
We have a dependencies verification feature enabled in the repository for all Gradle builds. Gradle will check hashes (md5 and sha256) of used dependencies and will fail builds with Dependency verification failed errors when local artifacts are absent or have different hashes listed in the verification-metadata.xml file.
It's expected that verification-metadata.xml should only be updated with the commits that modify the build. There are some tips how to perform such updates:
components section of verification-metadata.xml to avoid stockpiling of old unused dependencies. You may use the following command:#macOS sed -i '' -e '/<components>/,/<\/components>/d' gradle/verification-metadata.xml #Linux & Git for Windows sed -i -e '/<components>/,/<\/components>/d' gradle/verification-metadata.xml
--write-verification-metadata command (verify update relates to your changes)./gradlew --write-verification-metadata sha256 -Pkotlin.native.enabled=true resolveDependencies
resolveDependencies task resolves dependencies for all platforms including dependencies downloaded by plugins.
You can also use ./scripts/update-verification-metadata.sh script which includes both of these steps
Keep in mind:
darwin, mac, osx, linux, windows), remember to add them to implicitDependencies configuration or update resolveDependencies task if needed. resolveDependencies should resolve all dependencies including dependencies for different platforms.local.properties file in your Kotlin project folder, make sure that it doesn't contain kotlin.native.enabled=false. Otherwise, native-only dependencies may not be added to the verification metadata. This is because local.properties has higher precedence than the -Pkotlin.native.enabled=true specified in the Gradle command.We publish -dev versions frequently.
For -dev versions you can use the list of available versions and include this maven repository:
maven("https://redirector.kotlinlang.org/maven/bootstrap")
Kotlin is distributed under the terms of the Apache License (Version 2.0). See license folder for details.
Please be sure to review Kotlin's contributing guidelines to learn how to help the project.
The Kotlin Foundation is a non-profit organization whose mission is to promote and advance the Kotlin ecosystem. You can learn more about the structure and goals of the Kotlin Foundation on its official website.