Setup CI for macos15 with qt6

[vifactor]

No description provided.

[hannesa2]

Please consider to extend matrix. Preparation is here #675
And in my point of view, a move to qt6 should also happen on Linux and Windows too

[hannesa2]

Sorry, with this way, you have a lot of boiler plate code in github action.

[hannesa2]

Please rebase to recent master and here #677 you have an idea, how to extend the matrix

[vifactor]

I agree this leads to some boilerplate, but I did not want to extend that matrix intentionally to check Qt6. Anyway, this is just a draft which I have not finished and maybe will never do.

[hannesa2]

Btw, there is an other draft too #405

[vifactor]

And in my point of view, a move to qt6 should also happen on Linux and Windows too

I agree, but not necessarily simultaneously. Btw, migration to Qt6 has already happened on ubuntu 24.04.

Btw, there is an other draft too #405

I know, that PR was too scary to touch. My goal was simply add a new job to check macos-15 + Qt6 build without packaging. Since I do not have macos, it would be close to impossible for me to check produced package even if I figure out how to produce one.

[vifactor]

@hannesa2 if you have a mac machine, this PR now generates a mac bundle, would you be able to check whether app can be launched from the bundle?

[hannesa2]

[hannesa2]

Using the matrix and not introduce a new job, would avoid the start problems on MacOS.
Signing and notarization is in matrix out of the box

[vifactor]

Using matrix is good to save on code, but in this case important thing is to make build with qt6 working. The problem with existing packaging code is that it is crafted for qt5, is full of obsolete and hardcoded assumptions which are hard to fix in such a way that it works both with qt5 amnd qt6. Here, I am trying to come up with a minimal setup which would allow me to produce a working macos 15 bundle with qt6

[bunty95]

If RPATH is toggled to "ON" it should correct some of qt libraries being embedded into the .app file
Possibly we can use this template with QT5 and integrate notarization.

[bunty95]

DDLT_USE_QT_RPATH=ON

[vifactor]

I spent quite some time to find out that this option leads to some rpath garbage with qt6 and macos 15, which in turn leads to macdeployqt tool failure

[bunty95]

Added notarization to this PR. It now runs on without issue.

[hannesa2]

Added notarization to this PR. It now runs on without issue.

I see no reason to duplicate this. With an new build_cmake_qt6.sh and add it the matrix you probably avoid this boilerplate code

[vifactor]

@bunty95 @hannesa2 I do not have mac, but because I desperately want us to migrate to qt6, I made this work blindly relying on ci. Further progress on my side is not possible. please help me first to fix the bundle, then we can decide how to proceed

[bunty95]

@hannesa2 agree, only problem is that notarization for qt5 and qt6 is different. which is why the boiler plate for signing is added.
Should qt5 support be dropped for macOS?
I dont see a need to have both.

[bunty95]

Also do we need macOS 13, 14, and 15? I think we can drop macOS 14 since arm64 is captured by macOS 15, and intel is captured by macOS 13.

[hannesa2]

For my point of view, when qt6 is working, we don't need qt5 anymore.
But I don't want to decide this
@alexmucde

[hannesa2]

Also do we need macOS 13, 14, and 15? I think we can drop macOS 14 since arm64 is captured by macOS 15, and intel is captured by macOS 13.

There I've no opinion. But currently nothing hurt here.
Important is, that we have arm64 and x86. But even x86 is questionable.

[bunty95]

Also do we need macOS 13, 14, and 15? I think we can drop macOS 14 since arm64 is captured by macOS 15, and intel is captured by macOS 13.

There I've no opinion. But currently nothing hurt here. Important is, that we have arm64 and x86. But even x86 is questionable.

Once apple drops x86 from macOS, we can drop it from project

[nickelpot]

I tested it on macOS 15.5.

I can open the app file

About the dmg file, it doesn't work if I just run it (in dmg or move it into Applications folder)

Because from macOS 15.1, you can't run unsigned applications on macOS.
https://www.osnews.com/story/141055/bug-or-intentional-macos-15-1-completely-removes-ability-to-launch-unsigned-applications/
https://hackaday.com/2024/11/01/apple-forces-the-signing-of-applications-in-macos-sequoia-15-1/

I don't know how this application codesigning works. However, I can test running this app with some tweek.
You can run the app in DMG file after run this command: xattr -c <your path>/DLTViewer.app && codesign --force --deep -s - <your path>/DLTViewer.app

[bunty95]

I tested it on macOS 15.5.

I can open the app file

About the dmg file, it doesn't work if I just run it (in dmg or move it into Applications folder) Because from macOS 15.1, you can't run unsigned applications on macOS. https://www.osnews.com/story/141055/bug-or-intentional-macos-15-1-completely-removes-ability-to-launch-unsigned-applications/ https://hackaday.com/2024/11/01/apple-forces-the-signing-of-applications-in-macos-sequoia-15-1/

I don't know how this application codesigning works. However, I can test running this app with some tweek. You can run the app in DMG file after run this command: xattr -c <your path>/DLTViewer.app && codesign --force --deep -s - <your path>/DLTViewer.app

Thank you for double checking. using the "--force" is not the correct way to sign a ".dmg".
I will look into the correct method to do this, but for now the ".app" will be bundled, along with a release on the appstore.