Is .dmg not the macOS convention any more?

Is .dmg not the macOS convention any more?

I can't speak to this authoritatively, but I always found them a bit annoying. Since this is actually getting into UX, I tried to find a some references for my hunch:

• John Gruber complained about this in 2009: How Should Mac Apps Be Distributed?
• Apple did recommend images at some point, I believe, but the current guide only speaks of archives: Distribute outside the Mac App Store (macOS).
• The only relevant post I could find on Stack Overflow isn't terribly informative — and from 2010: DMG or Zip file for distribution to Macs?

Apple's guide only mentions archives and installer packages. Safari transparently extracts archives, and the Installer offers to move packages to the trash after processing, so either leads to a more pleasant experience in my opinion.

Unfortunately, all that won't matter much unless the product is signed somehow, as that triggers a dialog that prevents launching the application unless you right-click it.

One other advantage is that creating an archive is faster than creating the disk image.

I'm not aware of any advantage of .dmg other than convention. Historically they were used to preserve the resource forks, folder layout etc. I don't know if that still holds.

I found the same links you did, and nothing current from Apple recommending .dmg.

I see you mentioned "fixup", it looks like nightly build fails at this step.
Maybe you can help me to understand what's wrong.

I see you mentioned "fixup", it looks like nightly build fails at this step.
Maybe you can help me to understand what's wrong.

Well, it does appear to run into some permissions issues after copying dependencies — which seems a bit odd. What are the user accounts used during the build? Does the install happen with the same user as the actual build?

I fixed the issue with b145ee3 but make install is still broken in master branch, and I think this PR will solve that.

I fixed the issue with b145ee3 but make install is still broken in master branch, and I think this PR will solve that.

I pushed a change so that it should try this out on my branch. We'll see if it addresses this. One of the motivations for this change was that CPack seemed a bit crufty and weird compared to generating the bundle during build.

I fixed the issue with b145ee3 but make install is still broken in master branch, and I think this PR will solve that.

Nope; the change I pushed yesterday gets the exact same error, sadly. But I've pushed another applying the same fix you did.

I've rebased the change onto master; could you please take another look?

Sorry it has been a while; we are currently working on migrating our release workflow from Azure Pipelines to GitHub Actions. During so, we also prepared the Mac builds so they can produce ARM builds and fixed several Mac OS related bundle issues.

During this work, we found out that depending on CPack saves us a lot of time and effort. And although I appreciate your stance on not-liking-dmg-files, I am not convinced that adding the additional code (which we would have to maintain) is worth it. The reason we switched to CMake to start with was to avoid having to maintain all the quirks OSes have ourselves :)

In result, I am leaning towards closing this PR in favour of CPack dmg. This is mainly because the arguments you bring forth dmg is not a nice way to distribute are rather thin, and when we look around (as a non-Mac-user), we still see many projects distribute their applications in dmg format.
This is not a: we-are-never-going-to-do-this, but currently I do not see in the balance of "more custom code" vs "do what-ever CPack does" why the former should win :) I can be convinced otherwise ;)