Darwin Build from source: Don't always copy qml files from qtbase

[doronbehar]

Hello,

In NixOS/nixpkgs#243298 we are trying to build musescore from source for Darwin users as well as Linux. We noticed that this line is problematic for us:

https://github.com/musescore/MuseScore/blob/v4.1.0/src/app/CMakeLists.txt#L360-L369

So we removed it with a patch we apply on our side. In general, Darwin users that have qt installed globally and visibly on their machine, shouldn't need these qml files to be copied. It would be great if you'd enable to not do that via a cmake flag.

Thanks.

[igorkorsukov]

You can make a PR with the implementation of your proposal

[doronbehar]

I wonder what made you install those files in the 1st place... In anycase, here's a proposal: #18666

[cbjeukendrup]

Does this really only apply to those QML files? If you can assume that the user has a global Qt installation of the correct version, can't that be used for everything (also for the binary files)?

The reason that we install those files, is that the app needs to be self-contained, because of course we cannot assume that every user has Qt installed. So I assume that your package manager would install Qt as a dependency of MuseScore, is that the case?

[doronbehar]

The reason that we install those files, is that the app needs to be self-contained, because of course we cannot assume that every user has Qt installed. So I assume that your package manager would install Qt as a dependency of MuseScore, is that the case?

For the purpose of this discussion, the answer is yes.

[bkunda]

@RomanPudashkin @shoogle FYI

[cbjeukendrup]

@doronbehar FYI: PR #23643 removes the MUE_COMPILE_INSTALL_QTQML_FILES option and removes this install command. It turns out that copying the QML files is not necessary for development builds, because those somehow take the QML files directly from the Qt installation folder; and for release builds, we now deploy only the QML files that are actually needed, using macdeployqt.

[doronbehar]

Thanks @cbjeukendrup for notifying! In our build system we set this cmake option to "OFF", indeed because we don't need these files. I'm glad to hear you have also reached this conclusion. I'm not sure I'd be able to help with testing #23643 though, because I don't have a Darwin machine and I can't use the Nixpkgs CI for this...

[cbjeukendrup]

That's fine! Only wanted to update you about this change :)

[doronbehar]

BTW another apple specific cmake option we set in our build, is this:

    # From some reason, in $src/build/cmake/SetupBuildEnvironment.cmake,
    # upstream defaults to compiling to x86_64 only, unless this cmake flag is
    # set
    "-DMUE_COMPILE_BUILD_MACOS_APPLE_SILICON=ON"

Perhaps you'd be interested in removing this cmake option as well?

[cbjeukendrup]

We have indeed done that in the current master branch. The CMAKE_OSX_ARCHITECTURES option is no longer touched by us, so by default a build for the current architecture will be created, and I think you can also use it for cross compiling; or you can set it to x86_64;arm64 to create a universal build, which is what we do now on our CI.

[cbjeukendrup]

(The reason that we used to set the architecture to x86_64 by default is that we were using Qt 5.15, and when you install that via the standard installer, you only get x86_64 binaries. So if one would then try to compile MuseScore on Apple Silicon, and CMake defaults to arm64 because that's the host architecture, the build would fail at the very end because linking fails. But now we are using Qt 6.2.4, which provides a Universal build, so that situation is over now.)