Provide instructions and helper scripts to generate dmg of homebrew-based build for macOS

[apfelkraut]

These proposed changes should help to build a darktable dmg image for macOS using Homebrew and independent of the chip architecture.

It is based on the discussion around building darktable on macOS using Homebrew, for details see https://github.com/darktable-org/darktable/issues/10583.

It allows building darktable for M1 (arm64), creating a darktable application bundle, and a dmg image as requested/discussed here https://github.com/darktable-org/darktable/issues/7564. It allows building the same for Intel (i386).

It was developed and tested on macOS 12.3.1 ("Monterey") running on a M1 MacbookAir.

For details see the included BUILD_hb.txt.

LIMITATIONS

• Created DMG will only be compatible to the macOS version it was created upon (and potentially any later version).
• Naturally the libraries that darktable is built upon will be as good as its currently provided homebrew packages. You might want to use "$ brew pin " to lock your working/verified setup.
• As of today homebrew ships lensfun 0.3.3 that is the successor of the last stable release 0.3.2. It is expected to be compatible and should not break existing edits based on 0.3.2 or before.
• For now additional darktable tools like darktable-curve-tool or darktable-noiseprofile are not part of the default application bundle.

MACOS SECURITY

• The DMG is not notarized with/at Apple by using this approach. If it is still required see the official BUILD.txt for further instructions.
• As the DMG is not notarized and the app bundle may not even be properly signed, it is still possible to install/run darktable at your own risk. To do so make sure to run "$ xattr -d com.apple.quarantine .dmg" on the DMG before installing.

NOTES

• It will be automatically build for the architecture you are currently on, either Apple Silicon (arm64) or Intel (i386).
• If you want to build for i386 on arm64 see https://stackoverflow.com/questions/64951024/how-can-i-run-two-isolated-installations-of-homebrew/68443301#68443301 about how to handle both enviroments in parallel.
• After creating the darktable application bundle (step 3) you can directly run the result by executing: $ package/darktable.app/Contents/MacOS/darktable --configdir .config/darktable/ --cachedir .cache/darktable/

REFERENCES This approach is heavily based on and inspired by:

• The official BUILD.txt instructions (MacPorts-based) by the darktable community
• http://clarkkromenaker.com/post/library-dynamic-loading-mac/
• https://gitlab.gnome.org/GNOME/gtk-mac-bundler
• https://github.com/auriamg/macdylibbundler/

[TurboGit]

@parafin : I let you review and approve this one for obvious reasons :) TIA.

[apfelkraut]

@TurboGit it would be a pity if there is no arm64 (M1) build for macOS of the upcoming 4.0 release.

Can I help somehow? Any chance to get this in?

[TurboGit]

@apfelkraut : Well I'm a GNU/Linux guy and knows next to nothing about MacOS.

That being said, this PR provides scripts and so even if not merged someone will be able to create a package for MacOS.

The question is really, do you step in to create the DMG for 4.0? If so I can record it in the group of packagers and put the DMG for M1 into the release page. And this imply that you need to stay around and help people having issues installing or even amend the package if some critical issues are found.

How does that sound?

And note also that I won't be able to test, I won't be able to help about MacOS, so I'll have to rely on your work as being properly tested. And yes I'm ready for this :)

[apfelkraut]

@TurboGit thanks for your reply. This sounds good. I would be happy to generate a DMG for M1 of 4.0 and help people with anything that is related to its specific creation process.

Please note the following:

• I am (currently) not able to notarize the generated DMG with Apple. This might be due to my missing knowledge/expertise or due to that I do not own (pay for) an Apple developer account. To my understandings people should still be able to run it, possibly with a security warning (?).
• I am not familiar with the darktable code base (yet) nor a serious developer ... I just wanted to see a native build for M1.
• I am on macOS 12.X ("Monterey") with no access to machines running earlier versions. This means that the DMG provided by me will only run on this version/generation of macOS.

[TurboGit]

I didn't know that package needed to be signed :( I think we should name the DMG with -unsigned-experiemental or something like that for this first iteration.

@parafin : You are our MacOS expert, do you have any insight to give here? TIA.

[parafin]

I intend to take a look at all this soon-ish. I can sign and may be able to provide M1 build too, though maybe through macports.

[parafin]

I've thought about this and see the following way forward:

• I won't be able to validate homebrew build instructions due to lack of time. Instead I will continue to maintain macports building for now. I may build native M1 package for 4.0 release too, but no promises.
• I suggest other people maintain homebrew instructions, e.g. we can merge this PR.
• Since our macOS CI uses homebrew too, it should be maintained by the same team. E.g. right now it suffers from #11934, I would appreciate someone taking a look at it ASAP (maybe it's reproducible locally).
• Target would be to implement #10360.
• Once CI homebrew-based DMG package is feature-complete (so at least the same as current macports releases) and working we can declare homebrew the main supported way and phase out macports maintenance.
• For releases after that I propose we take CI-built DMG as a base. It has a problem of not being signed or notarized, but I can still take care of it outside of CI. Or someone else can take over if (s)he has Apple Developer account (subscription).
• Another point is macOS version support. Homebrew isn't able to target releases older than build system. For 4.0 macports-way I aim to support 10.14, GitHub CI has 10.15 hosts, so it would be just bump of one version, I say it's totally fine. If GitHub phases out this older build servers, so be it, supporting older macOS releases turned out to be quite a burden.

Main point, as before, is that someone should regularly tend to homebrew support (both to instructions and CI scripts/configs). It won't be me.

[github-actions[bot]]

This pull request did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[zisoft]

I just followed the instructions in BUILD_hb.txt, steps 1 and 2 ran smoothly. The executable ./bin/darktable can be run from the command line and seems to work fine.

When trying to build the app bundle with step 3 (3_make_hb_darktable_package.sh) the scripts terminates with an error:

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load command with path: @loader_path/../lib/darktable found in: package/darktable.app/Contents/Resources/lib/darktable/plugins/libcolorbalance.so (for architecture x86_64), required for specified option "-rpath @loader_path/../lib/darktable @loader_path/../Resources/lib/darktable"

Anything I can do to get this fixed?

I am on a MacBook Pro 16 (2019) Intel, running MacOS Ventura 13.1, Xcode Version 14.2 (14C18)

[shonjir]

The problem is that the script does not discriminate between binaries that have an incorrect relative @loader_path and binaries that already have the correct @loader_path. The following patch limits the fix to binaries that have the incorrect path. It is tested and works on my Ventura box.

diff --git a/packaging/macosx/3_make_hb_darktable_package.sh b/packaging/macosx/3_make_hb_darktable_package.sh
index 0790408ca..078cca483 100755
--- a/packaging/macosx/3_make_hb_darktable_package.sh
+++ b/packaging/macosx/3_make_hb_darktable_package.sh
@@ -74,8 +74,12 @@ function reset_exec_path {
 
     # Handle libdarktable.dylib
     if [[ "$oToolLDependencies" == *"@rpath/libdarktable.dylib"* && "$1" != *"libdarktable.dylib"* ]]; then
-        echo "Resetting loader path for libdarktable.dylib of <$1>"
-        install_name_tool -rpath @loader_path/../lib/darktable @loader_path/../Resources/lib/darktable "$1"
+        # Only need to reset binaries that live outside of lib/darktable
+        oToolLoader=$(otool -l "$1" 2>/dev/null | grep '@loader_path' | cut -d\( -f1 | sed 's/^[[:blank:]]*path[[:blank:]]*//;s/[[:blank:]]*$//' )
+        if [[ "$oToolLoader" == "@loader_path/../lib/darktable" ]]; then
+            echo "Resetting loader path for libdarktable.dylib of <$1>"
+            install_name_tool -rpath @loader_path/../lib/darktable @loader_path/../Resources/lib/darktable "$1"
+        fi
     fi
 
     # Filter for any homebrew specific paths

[zisoft]

Yes, that works. Thank you!

Are you going to make a PR for this fix?

EDIT: Ah, sorry. I just saw you already did 👍