Control Skia symbols visibility across platforms (#1208)
To extract Skottie and other extensions from Skiko core, we need to expose certain private symbols from skia. This requires creating tasks to control the visibility of Skia symbols. To control visibility of symbols the following things were applied: ### JVM We are generating a lists of symbols that we want to export. To obtain the symbols we're doing the following: 1. Collecting all globally defined symbols from the core Skiko/Skia inputs: Skia static libraries plus core object files. 2. Collecting all undefined symbols from extension/module inputs. These represent symbols that extension modules need the core library to provide. 3. Adding JNI infrastructure symbols from the core exports, such as `Java_`, `JNI`, and `jvm`, so the JVM can still find the native entry points. 4. Intersecting the extension imports with the core exports. The result is the list of core symbols that should stay exported. Generated symbol list it then passed to the linker which hide symbols we don't need to have visible. ### Native For Native targets, Skia is linked into the final produced binary rather than exposed as a shared "core" library that extension modules link against. Because of that, Skia symbols do not need to remain externally visible for other Skiko modules to resolve against them. Since we are going to build Skia from our fork with Skia symbols public by default we need to hide them on native. ### WASM This PR does not include wasm parser as we don't need it. We can first create the wasm binary for extension functions and then provide them when compiling the core. This will allow to export only symbols that are needed by the extension modules automatically. This will be introduced in the PR with Skottie extraction. Closes [SKIKO-1142](https://youtrack.jetbrains.com/issue/SKIKO-1142)
Showing
Please register or sign in to comment