I am having troubles creating an `Intel` dmg from ...

# compose-desktop

[Alex Styl]

I am having troubles creating an Intel dmg from my mac m1 machine.

I installed a x86_64 version of the jdk using sdkman.

To make sure i am running a x86_64 version I do:

file $(which java)

// prints
/Users/alexstyl/.sdkman/candidates/java/17.0.3-zulu/bin/java: Mach-O 64-bit executable x86_64

but whenever i create a Dmg using:

./gradlew clean packageReleaseDmg

the output app is Application (Apple silicon) instead of Intel.

what am i missing here?

[Michael Paus]

Installing the Intel version like this may be problematic and also not necessary. I just downloaded the Intel JDK and unpacked it in some folder where it is normally not found and doesn’t conflict with the ARM JDK which is normally used. It is then sufficient to execute gradle with this Intel JDK, which then gets executed via Rosetta 2, to create an Intel app installer.

The following worked for me where JAVA_HOME is temporarily pointing to the Intel JDK:

(export JAVA_HOME=/Users/mpaus/Downloads/jdk-17.0.9+9/Contents/Home; ./gradlew clean desktopApp:packageReleaseDmg)

[Alex Styl]

that's what sdkman does 🙂 it handles the switching of the java home for you and keeps the java versions tidy.


thanks for the reply btw.

I run the commands using IDEA (and using the right JDK) and it worked. I then realized that I had set a default java home in my ~/.gradle/gradle.properties (org.gradle.java.home) and probably that's why changing the JAVA_HOME did not work for me

[Michael Paus]

If you want this switching and never forget to switch back and forth sdkman is ok. I just don’t like it but that’s just my personal taste.
In your second part you probably inherited the JDK that gradle was launched with. Do you see why I don’t like these implicit dependencies which are often forgotten 😉.

[Alex Styl]

Yeah can see why. Need a cold shower to chill from the hours I spent on this. 😅