Build DFTFringe on macOS and publish DMGs from CI

[Lucassifoni]

Note : this was done by Opus 5, picking up Dan's work in 75d9cc6. I'm happy to work and help as long as needed on it but will be AI-assisted since QT isn't my cup of tea.

---- BEGIN AI-assisted summary ----

Problems since the 2023 Mac build :

• pkg-config names were opencv (OpenCV 3) and Qt5Qwt6 (qwt built against Qt5), but
  DFTFringe.pro is now the Qt6 project file.
• -lz was missing, which cnpy.cpp has needed since npz support landed. The link
  could not have succeeded.
• QMAKE_MKDIR and QMAKE_PKG_CONFIG hard coded two different Homebrew prefixes, one
  Intel and one Apple silicon, so the block could not work on either machine.
• QMAKE_FULL_VERSION was set to the literal string APP_VERSION.
• INCLUDEPATH had a stray -I prefix and pointed at the plugins directory.

Everything now comes from pkg-config, so no Homebrew prefix is hard coded and the same project file works on both architectures.

CI

build-macos.yml builds on macos-15 and macos-15-intel and uploads one disk image
per architecture. make-release.yml attaches both to the draft release alongside the
Windows installer.

Not an universal binary. Homebrew ships single-architecture libraries, so a universal
build would mean rebuilding opencv, armadillo and qwt for both architectures and merging
them with lipo.

opencv@4, not opencv. Homebrew's opencv formula is now OpenCV 5. opencv@4
keeps all three platforms on the same major version.

Potential problems

Minimum macOS is 15. macos-13 and macos-14 github runners are retired or deprecated, so the binary
inherits that floor. The 6.2 release required Ventura. Going lower means building the
dependencies from source with an explicit deployment target.

The disk images are not notarised. That needs a paid Apple Developer ID. macOS
refuses to open the app from the Finder, users have to clear the quarantine flag once.
This is documented in the README. The workflow has no signing machinery, so adding notarisation later is purely additive.

The bundle is ad-hoc signed, which is a separate matter: arm64 code must carry at least an ad-hoc signature to execute at all, and macdeployqt invalidates the linker's signature when it rewrites install names.

Single source change

colormapviewerdlg looked for ColorMaps in applicationDirPath(), which inside a
bundle is Contents/MacOS. That directory may hold nothing but code: codesign reports
the .cmp files as unsigned code objects and the whole bundle signature is rejected. The
maps ship in Contents/Resources and the lookup falls back there under Q_OS_MAC. The
6.2 bundle has them in neither location, so the colour map viewer has never worked on
macOS.

Correctness

This branch makes DFTFringe build, it does not produce correct results on its
own without the bool mask PR.

[Lucassifoni]

Hi,
To me there’s a fair bit of work before merging or moving this one forward. Again, while a developer, this isn’t my ecosystem, but a few things still seem fishy to me.

• The colour maps dance doesn’t work yet contrary to what is claimed
• The signing of the package isn’t fully functional either, it needs to be improved
• The readme has been unnecessarily made verbose

On the choices made, the biggest are that it isn’t an universal intel + arm build but two builds, and that it only produces executables for Mac OS > 15.

I’m willing to put as much time on this as needed.

Best,
Lucas

[atsju]

Thank you very much for this work ! It's really valuable for Mac users.
I see no problem having a different installer between windows and Mac.

[Lucassifoni]

@atsju I'll wait for your CI-related PRs to land before rebasing and finishing

[Lucassifoni]

It looks like the lipo'd DMG will be 169MB. As of today's standards it's okay for me. I'll continue cleaning up and check if I manage to handle the missing color maps.

[Lucassifoni]

The software won't open unless the user adds a security exception, this is normal unless signed with a valid Apple Developer ID (99$/year). I don't have one as of today. If noone in the team has one, it will have to stay that way. I added shorter instructions in the Readme.

[gr5]

I'm not a MAC person, so no. Possibly @Interferometry has one? He did some work to get DFTF to build on the Mac a few years ago.

[Lucassifoni]

I re-downloaded their 6.2 build and it looks like it was indeed signed, I don't get a security exemption request.

[gr5]

Is it possible/easy to explain how to do this in the installer for mac people who don't know how? Or am I being silly?

As a minimum please explain how to do it here so that I can mention this on the interferometry group when we release this. Or maybe a link to a youtube video on how to do it.

[Lucassifoni]

Another issue to fix before considering the build correct, I did not try to launch it graphically (by double-clicking) before today, and it crashes due to a non-writable root directory issue : #354
It launches fine from a non-root directory launched from the terminal.

[atsju]

Hi @Lucassifoni
just to clarify, are there still modifications expected or is this the version to be merged ?

As this doesn't touch code itself, it's relatively safe to merge. Then George could do a release after Stellafane convention. Would be first official release for MacOS :)

[Lucassifoni]

Hi @atsju, I'd like to clean up a bit the CI before merging. Can this wait until eow ?

[atsju]

it can wait for even longer than that. I just wanted to clarify current status.

[gr5]

@Lucassifoni - are you still making progress on this? I don't want to rush you but I'm hoping you don't drop this project before it's done. Or is it done?

[Lucassifoni]

@gr5 sorry, my availability is a bit randomly distributed while on holiday (which is what allowed me to work on that in the first place !). I'll wrap it with the appimage builds as soon as I have a few contiguous hours.

[Lucassifoni]

Hi, I took the time to do the various README and comment changes I wanted.

A next step would be proper attestation, there is a chance I will need to get an Apple Developer ID in the next months, if that happens I'll come back to discuss potentially signing the build, which enables 1-click opening instead of adding an OS-level security exception (which Mac users who use "advanced" software are quite used to, but still, it's an annoyance).

[atsju]

I will look at both your PRs later today. Thank you for the update !

[atsju]

Look good. Thank you.

note: whichever of the linux or mac branch will merge first will create some small conflicts for the other branch. It will need some fixes.

[Lucassifoni]

Yes, make_release will conflict, I will handle it in whichever comes second.Envoyé de mon iPhoneLe 19 août 2026 à 19:00, Julien Staub ***@***.***> a écrit : @atsju approved this pull request. Look good. Thank you. note: whichever of the linux or mac branch will merge first will create some small conflicts for the other branch. It will need some fixes. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[gr5]

I assume @Lucassifoni can go ahead and merge these 2 PRs? Since these are approved I assume @Lucassifoni or @atsju can proceed with these.

[atsju]

Lucas I let you fix conflicts before we merge

[Lucassifoni]

Sorry for this bad transient state, I am trying a new IDE and the way it operates on open files modified by pulling tripped me. Fixing this.

[Lucassifoni]

The git history is quite inflated now. The changeset is still the 5 same files. I'd prefer rewriting this branch to a single clean commit over master if that's fine by you ?

[atsju]

I prefer the squash and rebase version you just applied. That's fine.

I will review and merge tomorrow.

Thank you !