New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M1 support #41
base: master
Are you sure you want to change the base?
M1 support #41
Conversation
@ge-org can we please have this merged and released? |
Hello @jizoquval, thank you for you work. I'm testing your change but it doesn't seem to work with my project. I have following configuration:
And then run:
But created XCFramework doesn't have
I'm using Kotlin 1.5.30 and Gradle 7.2. |
Hello, @ge-org ! Any luck on this? My team needs M1 support, so we're deciding if we should just add it ourselves and fork the repo here. |
Hello 👋🏻 I'm also waiting for merging M1 support to released version of this Gradle plugin. Maybe you should ask project owner about future plans for this task? |
I managed to get this working by uploading a built jar to our internal maven repo.
I see that this is coming from |
I also noticed that this is how I've enabled ios builds in my gradle file: kotlin {
....
listOf(
iosX64(),
iosArm64(),
iosSimulatorArm64()
).forEach {
it.binaries.framework {
....
}
}
....
} How can I get the |
I've just see that there is a new JetBrains plugin for creating XCFramework. That maybe a good replacement for this plugin. It Gradle configuration looks like that in new created project:
|
Thanks @dstranz. With this new plugin, where is the generated framework after running a |
@adamwaite Under the build folder you will have fat-framework and XCFrameworks. XCFrameworks/release is exactly what you need. This is my setup val xcf = XCFramework("YourLibName")
listOf(
iosX64(),
iosArm64(),
iosSimulatorArm64()
).forEach { target ->
target.binaries.framework {
baseName = "YourLibName"
xcf.add(this)
}
}
sourceSets {
val commonMain by getting
val androidMain by getting
val androidTest by getting
val iosX64Main by getting
val iosArm64Main by getting
val iosSimulatorArm64Main by getting
val iosMain by creating {
dependsOn(commonMain)
iosX64Main.dependsOn(this)
iosArm64Main.dependsOn(this)
iosSimulatorArm64Main.dependsOn(this)
}
}
And you can build it using next gradle command: |
@ge-org What's stopping from merging this? |
Has anyone published the fork of this PR, are they are not maintaining this anymore? |
Forked this pr and published it here 👍
|
So turns out there's a few issues with this pr. Before making an XCFramwork: macos (including simulators) arm64, x64, and x86 binaries need to be packed in a fat framework 🙃 I'm gonna make a pr for your fork to include the fixes @jizoquval |
Working build: pluginManagement {
repositories {
maven ("https://s01.oss.sonatype.org/content/repositories/releases/")
}
} id("io.github.luca992.multiplatform-swiftpackage") version "2.0.4-arm64" |
@jizoquval jizoquval#2 made a PR for your PR 😅 |
@luca992 Thanks, I will look at it tomorrow! |
…mworks building XCFramworks
Entry META-INF/gradle-plugins/com.chromaticnoise.multiplatform-swiftpackage.properties is a duplicate but no duplicate handling strategy has been set.
if (targets.isNotEmpty()) { | ||
val buildType = if (targets[0].linkTask.name.contains("Release")) "release" else "debug" | ||
baseName = configuration.packageName.value | ||
destinationDir = buildDir.resolve("bin/iosSimulatorUniversal/${buildType}Framework") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible this isn't honouring multiplatformSwiftPackage.outputDirectory
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
error: the path does not point to a valid framework: xxxx/build/bin/iosSimulatorUniversal/releaseFramework/xxx.framework
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I touched anything that would affect outputDirectory
. The intermediate build binaries stored in bin shouldn't affect outputDirectory
?
How did you cause that error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@luca992 I can provide example gradle file. Version 2.0.3
succeeds. But it seems this fork is generating the intermediate framework with the wrong filename. The output appears to be our manifest package name rather than defined baseName
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only seems to be the case for iosSimulatorUniversal
. Resolution to succeed build is to label baseName
the same as our manifest package name. But this means the wrong framework name for imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @jizoquval will take a look this week
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haven't been able to test changes yet. gave up trying to use checked out version. might it be possible to make another release on your repository @luca992 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure. I'll do that today
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markst try my new build 2.0.5-arm64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @luca992. @jizoquval those changes seems to have fixed the issue!
+1 on this issue |
how can i use this fork since the original one is abandoned? |
Created a new release with the latest changes for this pr: pluginManagement {
repositories {
maven ("https://s01.oss.sonatype.org/content/repositories/releases/")
}
} id("io.github.luca992.multiplatform-swiftpackage") version "2.0.5-arm64" |
thanks @luca992 . can't seem to use it yet:
|
@markst If you tried immediately it probably wasn't indexed yet. Should be up now I think: https://repo1.maven.org/maven2/io/github/luca992/multiplatform-swiftpackage/io.github.luca992.multiplatform-swiftpackage.gradle.plugin/ |
Yeah. Gradle resolved it for me. Just tried |
its working! thanks |
Hi there, any news on this PR? I do experiment this issue and the fix @luca992 provided is working fine on my side, but it is still a little bit hacky to use a fork for this fix instead of an approved release. |
Idk not up to me 🤷♂️. Ps. The macos fat framework workaround can now be removed on kotlin 1.8 dev builds and be ported over to how the fat frameworks are being generated for the other targets. |
@luca992 changes are working also fine on my side. So what is still the issue with integrating the changes? |
Kotlin 1.8.0-beta is out. That macOs fat framework workaround now could probably be removed now to match all the other targets. |
They clearly aren't maintaining this. I updated my fork with a new release using kotlin 1.8.0 that removes my hacky macOs fat framework workaround. I don't see the point in submitting more pr updates here until someone responds, and I will just maintain my own fork 🙃. // build.gradle.kts
plugins {
// projects targting kotlin >=1.8.0
id("io.github.luca992.multiplatform-swiftpackage") version "2.1.4"
// projects targting kotlin <1.8.0
id("io.github.luca992.multiplatform-swiftpackage") version "2.0.5-arm64"
} |
Hey @luca992 - Just playing around with your fork on a new project. After running I'm not sure if this directly relates to your fork. But here's the project . |
@LukeSmith16 yeah idk off hand. I'll take a look. One thing to note... Sometimes I have to run |
@luca992 Thanks for the reply! Yeah so if i drag the package locally into xcode it works fine. It's just when i fetch it remotely it can't locate the dsyms. I thought this could have been .gitignore not including the dsym files, but it's not 😢 - I will keep trying to figure out why this isn't working for me but maybe i think it's not related to your fork as it's working locally fine. |
@LukeSmith16 you didn't check-in the files in the dsyms folders. My project for reference: |
@luca992 Yeah i'm having to check those dsym files in manually at the moment. I don't know why GIT isn't picking them up 🤔 - But yeah i got it working after manually checking them in, thanks for the help 👍 |
Hey dear, I still don't understand if this problem is solved or not, I still have a problem ((( |
should be working with my fork: |
Attention
This repo is not maintained anymore. Please use @luca992 fork.
Changed
Fixed