@@ -25,43 +25,15 @@ apply(plugin = "pub-conventions")
25
25
wasmWasi --------------------> jsAndWasmShared ----------+
26
26
|
27
27
V
28
- jvmCore\ --------> jvm ---------> concurrent -------> common
29
- jdk8 / ^
30
- |
28
+ jvm ----------------------------> concurrent -------> common
29
+ ^
31
30
ios \ |
32
31
macos | ---> nativeDarwin ---> native ---+
33
32
tvos | ^
34
33
watchos / |
35
34
|
36
35
linux \ ---> nativeOther -------+
37
36
mingw /
38
-
39
-
40
- Explanation of JVM source sets structure:
41
-
42
- The overall structure is just a hack to support the scenario we are interested in:
43
-
44
- * We would like to have two source-sets "core" and "jdk8"
45
- * "jdk8" is allowed to use API from Java 8 and from "core"
46
- * "core" is prohibited to use any API from "jdk8"
47
- * It is okay to have tests in a single test source-set
48
- * And we want to publish a **single** artifact kotlinx-coroutines-core.jar that contains classes from both source-sets
49
- * Current limitation: only classes from "core" are checked with animal-sniffer
50
-
51
- For that, we have following compilations:
52
- * jvmMain compilation: [jvmCoreMain, jdk8Main]
53
- * jvmCore compilation: [commonMain]
54
- * jdk8 compilation: [commonMain, jvmCoreMain]
55
-
56
- Theoretically, "jvmCore" could've been "jvmMain", it is not for technical reasons,
57
- here is the explanation from Seb:
58
-
59
- """
60
- The jvmCore is theoretically not necessary. All code for jdk6 compatibility can be in jvmMain and jdk8 dependent code can be in jdk8Main.
61
- Effectively there is no reason for ever putting code into jvmCoreMain.
62
- However, when creating a new compilation, we have to take care of creating a defaultSourceSet. Without creating the jvmCoreMain source set,
63
- the creation of the compilation fails. That is the only reason for this source set.
64
- """
65
37
========================================================================== */
66
38
67
39
kotlin {
@@ -109,35 +81,7 @@ kotlin {
109
81
}
110
82
}
111
83
112
- /* *
113
- * See: https://youtrack.jetbrains.com/issue/KTIJ-25959
114
- * The introduction of jvmCore is only for CLI builds and not intended for the IDE.
115
- * In the current setup there are two tooling unfriendly configurations used:
116
- * 1: - jvmMain, despite being a platform source set, is not a leaf (jvmCoreMain and jdk8Main dependOn it)
117
- * 2: - jvmMain effectively becomes a 'shared jvm' source set
118
- *
119
- * Using this kludge here, will prevent issue 2 from being visible to the IDE.
120
- * Therefore jvmMain will resolve using the 'single' compilation it participates in (from the perspective of the IDE)
121
- */
122
- val jvmCoreMain = if (Idea .active) null else sourceSets.create(" jvmCoreMain" ) {
123
- dependsOn(sourceSets.jvmMain.get())
124
- }
125
- val jdk8Main = sourceSets.create(" jdk8Main" ) {
126
- dependsOn(sourceSets.jvmMain.get())
127
- }
128
-
129
84
jvm {
130
- compilations.named(" main" ) {
131
- jvmCoreMain?.let { source(it) }
132
- source(jdk8Main)
133
- }
134
-
135
- /* Create compilation for jvmCore to prove that jvmMain does not rely on jdk8 */
136
- compilations.create(" CoreMain" ) {
137
- /* jvmCore is automatically matched as 'defaultSourceSet' for the compilation, due to its name */
138
- tasks.getByName(" check" ).dependsOn(compileTaskProvider)
139
- }
140
-
141
85
// For animal sniffer
142
86
withJava()
143
87
compilations.create(" benchmark" ) { associateWith(this @jvm.compilations.getByName(" main" )) }
0 commit comments