Broken CMakefile in 4.4.0 release

[darix]

Issue type

Other type of issue

Description with steps to reproduce

-- Configuring freetype <>
CMake Error at src/framework/draw/CMakeLists.txt:126 (harfbuzz_Populate):
  Unknown CMake command "harfbuzz_Populate".
Call Stack (most recent call first):
  src/framework/draw/CMakeLists.txt:126 (cmake_language)

-- Configuring incomplete, errors occurred!

Supporting files, videos and screenshots

-

What is the latest version of MuseScore Studio where this issue is present?

4.4.0

Regression

No.

Operating system

openSUSE Tumbleweed

Additional context

-

Checklist

• [X] This report follows the guidelines for reporting bugs and issues
• [X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• [X] I have attached all requested files and information to this report
• [X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

[darix]

I am a bit confused about this code

    # add harfbuzz
    # in the future this needs to be moved to some function in a separate file
    set(REMOTE_ROOT_URL https://raw.githubusercontent.com/musescore/muse_deps/main)
    set(remote_url ${REMOTE_ROOT_URL}/harfbuzz/7.1.0)
    set(local_path ${CMAKE_CURRENT_LIST_DIR}/_deps/harfbuzz)
    if (NOT EXISTS ${local_path}/harfbuzz.cmake)
        file(MAKE_DIRECTORY ${local_path})
        file(DOWNLOAD ${remote_url}/harfbuzz.cmake ${local_path}/harfbuzz.cmake
            HTTPHEADER "Cache-Control: no-cache"
        )
    endif()

    include(${local_path}/harfbuzz.cmake)

    # func from ${name}.cmake)
    cmake_language(CALL harfbuzz_Populate ${remote_url} ${local_path} "source" "" "")

    add_subdirectory(_deps/harfbuzz/harfbuzz)
    target_no_warning(harfbuzz -Wno-conversion)
    target_no_warning(harfbuzz -Wno-unused-parameter)
    target_no_warning(harfbuzz -Wno-unused-variable)
    target_no_warning(harfbuzz -WMSVC-no-hides-previous)
    target_no_warning(harfbuzz -WMSVC-no-unreachable)

    #add_subdirectory(thirdparty/msdfgen)

    set(MODULE_INCLUDE
        ${FREETYPE_INCLUDE_DIRS}
        ${CMAKE_CURRENT_LIST_DIR}/_deps/harfbuzz/harfbuzz/harfbuzz/src
        #${CMAKE_CURRENT_LIST_DIR}/thirdparty/msdfgen/msdfgen-1.4
    )

    set(MODULE_DEF ${MODULE_DEF} -DMUSE_MODULE_DRAW_USE_QTTEXTDRAW)

    set(MODULE_LINK ${FREETYPE_LIBRARIES} harfbuzz )#msdfgen)

why would it try to access the network during the build?

2. the devel packages for freetype and harfbuzz are actually available

rpm -qa freetype\* harfbuzz\*
freetype2-devel-2.13.2-2.2.x86_64
harfbuzz-devel-9.0.0-1.1.x86_64

[darix]

for the sake of completeness our spec file is here https://build.opensuse.org/projects/multimedia:apps/packages/musescore/files/musescore.spec?expand=1

[darix]

oh and we use the autogenerated tarball from github https://github.com/musescore/MuseScore/archive/refs/tags/v4.4.0.tar.gz

[doronbehar]

I too encountered this issue, on NixOS. I disabled this feature that uses relies upon this dinosaur harfbuzz (7.1.0 instead of 9.0.0) with the CMake flag -DDRAW_NO_INTERNAL=ON. It'd be nice also if using the system's harfbuzz was supported as well - cc @igorkorsukov per https://github.com/musescore/MuseScore/pull/19795 and https://github.com/musescore/MuseScore/issues/11572 .

Even with the CMake flag -DDRAW_NO_INTERNAL=ON, I encountered a different, linking issue that I suspect is related to the drawing module:

musescore> FAILED: src/framework/draw/tests/muse_draw_tests
musescore> : && /nix/store/lbk30k56awz9vz9qpid93fkjns0xwlhd-gcc-wrapper-13.3.0/bin/g++ -O2  src/framework/draw/tests/CMakeFiles/muse_draw_tests.dir/muse_draw_tests_autogen/mocs_compilation.cpp.o src/framework/draw/tests/CMakeFiles/muse_draw_tests.dir/__/__/testing/gmain.cpp.o src/framework/draw/tests/CMakeFiles/muse_draw_tests.dir/__/__/testing/environment.cpp.o src/framework/draw/tests/CMakeFiles/muse_draw_tests.dir/painter_tests.cpp.o -o src/framework/draw/tests/muse_draw_tests  lib/libgmock.a  src/framework/global/libmuse_global.a  src/framework/draw/libmuse_draw.a  lib/libgtest.a  src/framework/global/libmuse_global.a  -lz  /nix/store/45v73bvjwkjsprmmw2hwi9nfdn4k1z0r-tinyxml2-10.0.0/lib/libtinyxml2.a  -ldl  /nix/store/801icna0rjv9l0s3chxvq97gyz86vrab-qtnetworkauth-6.7.2/lib/libQt6NetworkAuth.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6QuickControls2.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6QuickTemplates2.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6QuickWidgets.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6Quick.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6QmlModels.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6Qml.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Network.so.6.7.2  /nix/store/ywzvg8m6h5a04g4vzrw0a0ak5mzxcrq6-qtdeclarative-6.7.2/lib/libQt6QmlBuiltins.a  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Xml.so.6.7.2  /nix/store/313b8qakx8w0506ldqy1mrvspsjp147n-qtsvg-6.7.2/lib/libQt6Svg.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6PrintSupport.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Widgets.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6OpenGL.so.6.7.2  /nix/store/d61pm1wvarlyqxmsf047sdv8msw2h6ak-qt5compat-6.7.2/lib/libQt6Core5Compat.so.6.7.2  /nix/store/x5x51kzd2369ixya8hzvps8b76dgzyvw-qtscxml-6.7.2/lib/libQt6StateMachine.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Gui.so.6.7.2  /nix/store/lnqwj5a3rl82rp96kxzxqdhzvz98scwb-libglvnd-1.7.0/lib/libGLX.so  /nix/store/lnqwj5a3rl82rp96kxzxqdhzvz98scwb-libglvnd-1.7.0/lib/libOpenGL.so  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Concurrent.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6DBus.so.6.7.2  /nix/store/62rz6d59b1pi3pwx9yxc8q3aak2xlmz3-qtbase-6.7.2/lib/libQt6Core.so.6.7.2 && :
musescore> /nix/store/x7yyxvwy1f9hlx72rzrgx069jyf7hxwr-binutils-2.42/bin/ld: src/framework/draw/tests/CMakeFiles/muse_draw_tests.dir/painter_tests.cpp.o: in function `getUnderlyingQPainter(muse::draw::Painter const*)':
musescore> painter_tests.cpp:(.text+0x2f): undefined reference to `typeinfo for muse::draw::QPainterProvider'
musescore> /nix/store/x7yyxvwy1f9hlx72rzrgx069jyf7hxwr-binutils-2.42/bin/ld: painter_tests.cpp:(.text+0x45): undefined reference to `muse::draw::QPainterProvider::qpainter() const'
musescore> /nix/store/x7yyxvwy1f9hlx72rzrgx069jyf7hxwr-binutils-2.42/bin/ld: src/framework/draw/libmuse_draw.a(unity_0_cxx.cxx.o): in function `muse::draw::Painter::Painter(QPaintDevice*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
musescore> unity_0_cxx.cxx:(.text+0x1117b): undefined reference to `muse::draw::QPainterProvider::make(QPaintDevice*)'
musescore> /nix/store/x7yyxvwy1f9hlx72rzrgx069jyf7hxwr-binutils-2.42/bin/ld: src/framework/draw/libmuse_draw.a(unity_0_cxx.cxx.o): in function `muse::draw::Painter::Painter(QPainter*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)':
musescore> unity_0_cxx.cxx:(.text+0x11373): undefined reference to `muse::draw::QPainterProvider::make(QPainter*, bool)'
musescore> collect2: error: ld returned 1 exit status

[jamesjer]

I just ran into this while trying to build for Fedora. It looks like harfbuzz is needed only to build the bundled version of freetype. We pass -DMUE_COMPILE_USE_SYSTEM_FREETYPE:BOOL=ON to cmake, so I believe harfbuzz isn't needed. In any case, as the others are reporting, our builders have no Internet access, so downloading stuff during the build is not an option.

[darix]

we had that -DMUE_COMPILE_USE_SYSTEM_FREETYPE:BOOL=ON already but as you see in the output it fails to find it without really telling me why.

FWIW: Just to be sure I did:

abuild@5f3ae3dac042:~/rpmbuild/BUILD/MuseScore-4.4.0/build> cmake -DMUE_COMPILE_USE_SYSTEM_FREETYPE:BOOL=ON ..
[snip]
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.13.2")
-- Found freetype: 2.13.2
CMake Error at src/framework/draw/CMakeLists.txt:126 (harfbuzz_Populate):
  Unknown CMake command "harfbuzz_Populate".
Call Stack (most recent call first):
  src/framework/draw/CMakeLists.txt:126 (cmake_language)

-- Configuring incomplete, errors occurred!

[jamesjer]

It looks like 31 lines starting at # add harfbuzz should be wrapped in if (NOT MUE_COMPILE_USE_SYSTEM_FREETYPE) ... endif().

[darix]

yeah seems to pass cmake with

Index: MuseScore-4.4.0/src/framework/draw/CMakeLists.txt
===================================================================
--- MuseScore-4.4.0.orig/src/framework/draw/CMakeLists.txt
+++ MuseScore-4.4.0/src/framework/draw/CMakeLists.txt
@@ -108,6 +108,7 @@ else()

     include(cmake/SetupFreeType.cmake)

+    if (NOT MUE_COMPILE_USE_SYSTEM_FREETYPE)
     # add harfbuzz
     # in the future this needs to be moved to some function in a separate file
     set(REMOTE_ROOT_URL https://raw.githubusercontent.com/musescore/muse_deps/main)
@@ -143,6 +144,7 @@ else()
     set(MODULE_DEF ${MODULE_DEF} -DMUSE_MODULE_DRAW_USE_QTTEXTDRAW)

     set(MODULE_LINK ${FREETYPE_LIBRARIES} harfbuzz )#msdfgen)
+    endif()

 endif()

but it later fails to find msdfgen.h.

make  -f src/appshell/CMakeFiles/appshell.dir/build.make src/appshell/CMakeFiles/appshell.dir/build
In file included from /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/draw/CMakeFiles/muse_draw.dir/Unity/unity_1_cxx.cxx:37:
/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/draw/internal/fontsengine.cpp:25:10: fatal error: msdfgen.h: No such file or directory
   25 | #include <msdfgen.h>
      |          ^~~~~~~~~~~
compilation terminated.
make[2]: *** [src/framework/draw/CMakeFiles/muse_draw.dir/build.make:104: src/framework/draw/CMakeFiles/muse_draw.dir/Unity/unity_1_cxx.cxx.o] Error 1
make[2]: Target 'src/framework/draw/CMakeFiles/muse_draw.dir/build' not remade because of errors.

does this refer to https://github.com/Chlumsky/msdfgen/ ?

-DDRAW_NO_INTERNAL=OFF does not seems to help either.

[jamesjer]

I think you got a couple of lines too many inside the if. See https://github.com/musescore/MuseScore/pull/24247.

[darix]

naw it seems to proceed -DDRAW_NO_INTERNAL=ON ... that option is just weirdly named TBH. Question still remains if the internal drawing code should work with system freetype and harfbuzz. and if yes ... it should also probably check for the msdfgen.h with cmake and error out if it cant find the header.

[darix]

my build with the non internal drawing code fails at

[ 77%] Building CXX object src/framework/update/tests/CMakeFiles/update_test.dir/__/__/testing/gmain.cpp.o
cd /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/update/tests && /usr/bin/ccache /var/lib/build/ccache/bin/c++ -DKORS_LOGGER_QT_SUPPORT -DKORS_PROFILER_ENABLED -DMUE_BUILD_APPSHELL_MODULE -DMUE_BUILD_BRAILLE_MODULE -DMUE_BUILD_CONVERTER_MODULE -DMUE_BUILD_IMAGESEXPORT_MODULE -DMUE_BUILD_IMPORTEXPORT_MODULE -DMUE_BUILD_INSPECTOR_MODULE -DMUE_BUILD_INSTRUMENTSSCENE_MODULE -DMUE_BUILD_NOTATION_MODULE -DMUE_BUILD_PALETTE_MODULE -DMUE_BUILD_PLAYBACK_MODULE -DMUE_BUILD_PROJECT_MODULE -DNDEBUG -DQT_CONCURRENT_LIB -DQT_CORE5COMPAT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORKAUTH_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB -DQT_QMLBUILTINS_LIB -DQT_QMLINTEGRATION_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKTEMPLATES2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_STATEMACHINE_LIB -DQT_SUPPORT -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -DSCRIPT_INTERFACE -DSYSTEM_TINYXML -Dmuse_global_QML_IMPORT=\"\" -Dmuse_update_QML_IMPORT=\"/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/update/qml\" -Dupdate_test_DATA_ROOT=\"/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/update/tests\" -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/update/tests -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/update/tests -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/update/tests/update_test_autogen/include -I/usr/include/qt6/QtDBus -I/usr/include/qt6/QtWidgets -I/usr/include/qt6/QtNetwork -I/usr/include/qt6/QtNetworkAuth -I/usr/include/qt6/QtQml -I/usr/include/qt6/QtQmlIntegration -I/usr/include/qt6/QtQmlBuiltins -I/usr/include/qt6/QtQuick -I/usr/include/qt6/QtQmlModels -I/usr/include/qt6/QtOpenGL -I/usr/include/qt6/QtQuickControls2 -I/usr/include/qt6/QtQuickTemplates2 -I/usr/include/qt6/QtQuickWidgets -I/usr/include/qt6/QtXml -I/usr/include/qt6/QtSvg -I/usr/include/qt6/QtPrintSupport -I/usr/include/qt6/QtCore5Compat -I/usr/include/qt6/QtStateMachine -I/usr/include/qt6/QtConcurrent -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0 -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/global -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/global -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/framework -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/framework/global -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/framework/testing/thirdparty/googletest/googletest/include -I/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/build.release/src/framework/update -isystem /usr/include/qt6/QtCore -isystem /usr/include/qt6 -isystem /usr/include/qt6/QtGui -isystem /usr/lib64/qt6/mkspecs/linux-g++ -isystem /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/testing/thirdparty/googletest/googlemock/include -isystem /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/testing/thirdparty/googletest/googlemock -isystem /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/testing/thirdparty/googletest/googletest/include -isystem /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/testing/thirdparty/googletest/googletest -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type  -g -O2 -g -DNDEBUG -std=gnu++17 -Wall -Wextra -MD -MT src/framework/update/tests/CMakeFiles/update_test.dir/__/__/testing/gmain.cpp.o -MF CMakeFiles/update_test.dir/__/__/testing/gmain.cpp.o.d -o CMakeFiles/update_test.dir/__/__/testing/gmain.cpp.o -c /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/testing/gmain.cpp
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: ../libmuse_draw.a(unity_0_cxx.cxx.o): in function `muse::draw::Painter::Painter(QPaintDevice*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/draw/painter.cpp:49:(.text+0x110fb): undefined reference to `muse::draw::QPainterProvider::make(QPaintDevice*)'
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: ../libmuse_draw.a(unity_0_cxx.cxx.o): in function `muse::draw::Painter::Painter(QPainter*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)':
/home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/draw/painter.cpp:56:(.text+0x111d3): undefined reference to `muse::draw::QPainterProvider::make(QPainter*, bool)'
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status

but that is something for after sleeping.

current package is here https://build.opensuse.org/package/show/home:darix:playground/musescore

[jamesjer]

Well, I can tell you that I got a successful build with that PR, using the system freetype and harfbuzz. I didn't need to add -DDRAW_NO_INTERNAL=ON.

[darix]

with your patch i run into

[   50s] /home/abuild/rpmbuild/BUILD/MuseScore-4.4.0/src/framework/draw/internal/fontfaceft.cpp:27:10: fatal error: ft2build.h: No such file or directory
[   50s]    27 | #include <ft2build.h>
[   50s]       |          ^~~~~~~~~~~~
[   50s] compilation terminated.

it checked for freetype2

grep -r freetype2
CMakeCache.txt:FREETYPE_INCLUDE_DIR_freetype2:PATH=/usr/include/freetype2
CMakeCache.txt:FREETYPE_INCLUDE_DIR_ft2build:PATH=/usr/include/freetype2
CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_Freetype:INTERNAL=[/usr/lib64/libfreetype.so][/usr/include/freetype2][v2.13.2()]
CMakeCache.txt://ADVANCED property for variable: FREETYPE_INCLUDE_DIR_freetype2
CMakeCache.txt:FREETYPE_INCLUDE_DIR_freetype2-ADVANCED:INTERNAL=1

but it seems that information isnt passed to that part.

[darix]

@jamesjer not sure if you want to include this into your pull request:

Index: MuseScore/src/framework/draw/CMakeLists.txt
===================================================================
--- MuseScore.orig/src/framework/draw/CMakeLists.txt
+++ MuseScore/src/framework/draw/CMakeLists.txt
@@ -136,7 +136,6 @@ else()
         #add_subdirectory(thirdparty/msdfgen)

         set(MODULE_INCLUDE
-            ${FREETYPE_INCLUDE_DIRS}
             ${CMAKE_CURRENT_LIST_DIR}/_deps/harfbuzz/harfbuzz/harfbuzz/src
             #${CMAKE_CURRENT_LIST_DIR}/thirdparty/msdfgen/msdfgen-1.4
         )
@@ -144,6 +143,8 @@ else()

     set(MODULE_DEF ${MODULE_DEF} -DMUSE_MODULE_DRAW_USE_QTTEXTDRAW)

+    set(MODULE_INCLUDE ${MODULE_INCLUDE} ${FREETYPE_INCLUDE_DIRS})
+
     set(MODULE_LINK ${FREETYPE_LIBRARIES} harfbuzz )#msdfgen)

 endif()

But even that change is not enough yet. it seems we are not checking for harfbuzz ... and HARFBUZZ_INCLUDE_DIRS is not set. but it tries to load harfbuzz header files like hb-ft.h.

right now i am testing with the ugly hack:

set(MODULE_INCLUDE ${MODULE_INCLUDE} ${FREETYPE_INCLUDE_DIRS} /usr/include/harfbuzz)

[darix]

fixed with https://build.opensuse.org/projects/home:darix:playground/packages/musescore/files/pass-in-freetype2.patch?expand=1

not sure if upstream wants to solve it quite like this but at least it gets the gist :)

[doronbehar]

fixed with build.opensuse.org/projects/home:darix:playground/packages/musescore/files/pass-in-freetype2.patch?expand=1

not sure if upstream wants to solve it quite like this but at least it gets the gist :)

That looks good @darix. (haven't had to time to try it yet). But I was wondering - did you copy that FindHarfBuzz.CMake file from somewhere? Here on NixOS we have a harfbuzz-config.cmake file which is part of the harfbuzz package that looks like this:

get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../../z4gc4b4118y5p9fwy02nzhivfwyxhxxj-harfbuzz-9.0.0" ABSOLUTE)

macro(set_and_check _var _file)
  set(${_var} "${_file}")
  if(NOT EXISTS "${_file}")
    message(FATAL_ERROR "File or directory ${_file} referenced by variable ${_var} does not exist !")
  endif()
endmacro()

macro(check_required_components _NAME)
  foreach(comp ${${_NAME}_FIND_COMPONENTS})
    if(NOT ${_NAME}_${comp}_FOUND)
      if(${_NAME}_FIND_REQUIRED_${comp})
        set(${_NAME}_FOUND FALSE)
      endif()
    endif()
  endforeach()
endmacro()

set_and_check(HARFBUZZ_INCLUDE_DIR "${PACKAGE_PREFIX_DIR}/../72ddhqsm72lbzdv1izi97fdxbc7215i8-harfbuzz-9.0.0-dev/include/harfbuzz")

# Add the libraries.
add_library(harfbuzz::harfbuzz SHARED IMPORTED)
set_target_properties(harfbuzz::harfbuzz PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${PACKAGE_PREFIX_DIR}/../72ddhqsm72lbzdv1izi97fdxbc7215i8-harfbuzz-9.0.0-dev/include/harfbuzz"
  IMPORTED_LOCATION "${PACKAGE_PREFIX_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}harfbuzz${CMAKE_SHARED_LIBRARY_SUFFIX}.0.60900.0")

add_library(harfbuzz::icu SHARED IMPORTED)
set_target_properties(harfbuzz::icu PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${PACKAGE_PREFIX_DIR}/../72ddhqsm72lbzdv1izi97fdxbc7215i8-harfbuzz-9.0.0-dev/include/harfbuzz"
  INTERFACE_LINK_LIBRARIES "harfbuzz::harfbuzz"
  IMPORTED_LOCATION "${PACKAGE_PREFIX_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}harfbuzz-icu${CMAKE_SHARED_LIBRARY_SUFFIX}.0.60900.0")

add_library(harfbuzz::subset SHARED IMPORTED)
set_target_properties(harfbuzz::subset PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${PACKAGE_PREFIX_DIR}/../72ddhqsm72lbzdv1izi97fdxbc7215i8-harfbuzz-9.0.0-dev/include/harfbuzz"
  INTERFACE_LINK_LIBRARIES "harfbuzz::harfbuzz"
  IMPORTED_LOCATION "${PACKAGE_PREFIX_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}harfbuzz-subset${CMAKE_SHARED_LIBRARY_SUFFIX}.0.60900.0")

# Only add the gobject library if it was built.
if (YES)
  add_library(harfbuzz::gobject SHARED IMPORTED)
  set_target_properties(harfbuzz::gobject PROPERTIES
    INTERFACE_INCLUDE_DIRECTORIES "${PACKAGE_PREFIX_DIR}/../72ddhqsm72lbzdv1izi97fdxbc7215i8-harfbuzz-9.0.0-dev/include/harfbuzz"
    INTERFACE_LINK_LIBRARIES "harfbuzz::harfbuzz"
    IMPORTED_LOCATION "${PACKAGE_PREFIX_DIR}/lib/${CMAKE_SHARED_LIBRARY_PREFIX}harfbuzz-gobject${CMAKE_SHARED_LIBRARY_SUFFIX}.0.60900.0")
endif ()

check_required_components(harfbuzz)

I wonder you can spare yourself adding that FindHarfBuzz.cmake file by adding the meson flag -Dcmakepackagedir=/usr/lib/cmake to your build of Harfbuzz.

[igorkorsukov]

To understand, tell us how you build applications that use package dependency managers such as conan, gradle, npm, etc.?

[darix]

@igorkorsukov #24247 alone is not good enough JFYI

[darix]

To understand, tell us how you build applications that use package dependency managers such as conan, gradle, npm, etc.?

i can not speak for the other distributions. but in the case for npm/golang/rust e.g. we have tooling that would create a vendor.tar.zst archive with all the vendored libraries. but we try to avoid that with all the other languages where we actually have the specific libraries packaged separately, as using intree copies would require us to fix security issues not just in the normal system library but also in the intree copy.

[igorkorsukov]

@darix How do you guarantee the correctness and stability of the applications?

For example, we know how our application works with harfbuzz 7, because we tested the use of this combination with our application and specific versions of other libraries... but we don't know how it will work with harfbuzz 9. Maybe there are some peculiarities, maybe there was a bug, maybe on the contrary, some bug was fixed (but our code takes into account the previous behavior), etc. Each version of each library has its own peculiarities...

[darix]

well that is always a chance that a version upgrade of a library breaks things. if that happens we work with upstream to upgrade to the newer version and work with them to patch the code to work with multiple versions e.g. atm the we are in this cycle for gcc14 (which is again stricter) and make ffmpeg 7 the default for every package in openSUSE Tumbleweed.

Hard locking to certain library versions is not a good solution. The software eco system will evolve around you and your hard locked versions might not work in the surrounding eco system anymore. ( like e.g. with a newer GCC or building against newer system libraries)

For many opensource projects we try to look at the changes they do and tell them "hey this would break in this situation is this intentional?" because distributions often want to keep a package running on multiple distro versions and we have a pretty good overview of integrating software in a larger scope.

[darix]

grep -E '^(Name=|StartupWMClass=)' /usr/share/applications/org.musescore.MuseScore.desktop
Name=MU 4.4
StartupWMClass=MuseScore 4 dev

that looks a bit like development code slipped into a release. found that when trying to launch musescore via gnome's launcher and was wondering why it wouldnt find "musescore" as search term anymore.

also the File Open dialog defaults to ~/Documents/MuseScore4Development/Scores

something is fishy here. And yes we are building with -DMUSESCORE_BUILD_MODE=release

and the build lacks the whole menu bar.

QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix
qt.qml.typeregistration: Invalid QML element name "IconCode"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "MusicalSymbolCodes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "ContainerType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "NavigationEvent"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "MUAccessible"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "CompareType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "SelectionMode"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "ToolBarItemType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "DockToolBarAlignment"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "Location"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "CloudVisibility"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "SaveToCloudResponse"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "DirectionTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "SlurTieTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "NoteHead"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "Beam"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "Hairpin"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "OrnamentTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "Dynamic"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "Glissando"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "CommonTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "BarlineTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "MarkerTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "KeySignatureTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "AccidentalTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "FretDiagramTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "LineTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "TextTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "ArticulationTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "AmbitusTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "ChordSymbolTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "BendTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "TremoloBarTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "TremoloTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "VoiceTypes"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "InstrumentsTreeItemType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "StandardButton"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "SaveLocationType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "GenerateAudioTimePeriodType"; value type names should begin with a lowercase letter
qt.qml.typeregistration: Invalid QML element name "MigrationType"; value type names should begin with a lowercase letter
12:35:36.287 | INFO  | main_thread     | GlobalModule::onPreInit | log path: ${HOME}/.local/share/MuseScore/MuseScore4Development/logs/MuseScore_240828_123536.log
12:35:36.287 | INFO  | main_thread     | GlobalModule::onPreInit | === Started MuseScore Studio Development 4.4.0, build:  ===
12:35:36.287 | INFO  | main_thread     | LanguagesService::effectiveLanguageCode | System language code: "en-US" 
12:35:36.288 | WARN  | main_thread     | IpcSocket::connect | failed connect to server
12:35:36.288 | WARN  | main_thread     | IpcSocket::connect | failed connect to server
12:35:36.288 | INFO  | main_thread     | IpcSocket::connect | success connected to ipc server
12:35:36.288 | INFO  | 140430008125120 | IpcServer::listen | id: "a8caaff2a94d4905aefdb79bf6fcc230" 
12:35:36.313 | WARN  | main_thread     | DiagnosticsModule::onInit | crash handling disabled
12:35:36.354 | ERROR | main_thread     | MuseSamplerLibHandler::MuseSamplerLibHandler | Unable to open MuseSampler library, path: ${HOME}/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so
12:35:36.354 | ERROR | main_thread     | MuseSamplerResolver::doInit | Incompatible MuseSampler library; ignoring
12:35:36.354 | ERROR | main_thread     | MuseSamplerLibHandler::MuseSamplerLibHandler | Unable to open MuseSampler library, path: libMuseSamplerCoreLib.so
12:35:36.354 | ERROR | main_thread     | MuseSamplerResolver::doInit | Incompatible MuseSampler library; ignoring
12:35:36.355 | WARN  | main_thread     | Qt              | QIODevice::read (QFile, "${HOME}/.local/share/MuseScore/MuseScore4Development/shortcuts.xml"): device not open
12:35:36.355 | WARN  | main_thread     | Qt              | QIODevice::read (QFile, "${HOME}/.local/share/MuseScore/MuseScore4Development/midi_mappings.xml"): device not open
12:35:36.366 | WARN  | main_thread     | AbstractCloudService::readTokens | Could not find the tokens file: ${HOME}/.local/share/MuseScore/MuseScore4Development/musescorecom_cred.dat
12:35:36.366 | WARN  | main_thread     | AbstractCloudService::readTokens | Could not find the tokens file: ${HOME}/.local/share/MuseScore/MuseScore4Development/audiocom_cred.dat
12:35:37.163 | ERROR | main_thread     | GuiApp::perform | error: qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"

12:35:37.164 | WARN  | main_thread     | Qt              | qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"
12:35:37.164 | ERROR | main_thread     | GuiApp::perform | error: qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"

12:35:37.164 | WARN  | main_thread     | Qt              | qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"
12:35:37.187 | WARN  | main_thread     | Qt              | Dropping not implement for QtQuick on Wayland yet!
12:35:37.212 | ERROR | main_thread     | ExtensionsConfiguration::manifestConfigs | failed read config data, err: [406] An error occurred when reading from the file, file: ${HOME}/.local/share/MuseScore/MuseScore4Development/plugins/plugins.json
12:35:37.239 | WARN  | main_thread     | Qt              | QObject::connect(DockToolBar_QMLTYPE_163, WindowContent_QMLTYPE_0): unique connections require a pointer to member function of a QObject subclass
12:35:37.239 | WARN  | main_thread     | Qt              | QObject::connect(DockToolBar_QMLTYPE_163, WindowContent_QMLTYPE_0): unique connections require a pointer to member function of a QObject subclass
12:35:37.239 | WARN  | main_thread     | Qt              | QObject::connect(DockToolBar_QMLTYPE_163, WindowContent_QMLTYPE_0): unique connections require a pointer to member function of a QObject subclass
12:35:38.314 | ERROR | main_thread     | UpdateScenario::doCheckForUpdate | Unable to check for update, error: [1701] 

[cbjeukendrup]

If the build lacks a menu bar, that's probably caused by Qt 6.7.2 (or rather 6.5+), see #24097.

Re. release mode: it's now called MUSE_APP_BUILD_MODE...

[darix]

If the build lacks a menu bar, that's probably caused by Qt 6.7.2 (or rather 6.5+), see #24097.

Thank you for the pointer

Re. release mode: it's now called MUSE_APP_BUILD_MODE...

Fixed in the package.

[cbjeukendrup]

Here is my attempt at supporting system harfbuzz for building: https://github.com/musescore/MuseScore/pull/24261

[darix]

@igorkorsukov and as you can see in #24097 my coworker might even have helped already to find why some UI elements arent shown. :)

[igorkorsukov]

and as you can see in https://github.com/musescore/MuseScore/issues/24097 my coworker might even have helped already to find why some UI elements arent shown. :)

But this can lead to bad consequences ( We are testing and debugging the work now on Qt 6.2 The application will be built and launched with Qt6.7 (Qt6.5+) and there will be a semblance of work, but there may be a variety of unexpected problems (for example, we now have a lot of problems with font rendering). Users will encounter these problems... They will even come here and write about their problems..., but we will not be able to do anything, we do not currently support Qt 6.7

This is a loss for everyone, both us and our users, no one wins, everyone loses :(

So for us this fix is ​​only good for the future when we move to Qt 6.7 and support it.

[darix]

how much of the trouble comes from your own drawing code? would that custom implementation still be needed on newer Qt versions?

[igorkorsukov]

We are currently drawing text using Qt. We only get some font metrics with our implementation. This is only needed for render of notation (not GUI, Qml) Is this needed in future versions? Who knows, the metrics suddenly broke, and are still broken in Qt 6.7 (The behavior has changed for specific fonts, the absence of some flags in a font file has begun to be interpreted differently)

Each version of Qt has its own specifics... Especially considering that we support three platforms, not one. We cannot support a different version of Qt for each platform and, accordingly, take into account all the specifics of all combinations.

And when MuseScore has problems in your distribution, users (regular) will have a bad opinion not about your distribution, but about our application.

I really hope that solutions like Flatpak will become popular and mainstream. As a Linux user, I am upset that Linux applications are of such low quality, even from a store, some do not launch, often do not work. And as a developer, I also avoid Linux, I don’t have the strength or time to support various combinations of all dependencies for different distributions.

That's how things are.

[igorkorsukov]

It would be great if the application was built and distributed with the dependencies it was tested with! Except for low-level ones, such as libс, or security-related ones, such as libssl, or system like alsa, or DE like color, file chooser.

Bu, it is definitely better to use the Qt for which the application was developed. It is not disk space that we are saving these days :)

[igorkorsukov]

From time to time, we encounter problems with Qt, and often one of the options before us is a Qt patch (we even did it once, for MacOS). For now, we avoid Qt patches. But who knows, maybe there will be no other choice for us... And then this whole system of getting dependencies from a distribution will not work at all.

Or, for example, we made a patch for another third-party lib (tinyxml), it's good that we do not take it from a distribution, but added it as sources. Otherwise, the import of MusicXML, which Sibelius exported, simply would not work.

[darix]

you are adding a lot of extra maintenance overhead with intree copies. e.g. last year or so there was a small bug in some container related tooling ... but because of the way of how golang works we had to touch 4+ packages because each had an intree copy.

with regards of tinyxml2. you allow building against the system copy and there is no warning that the system copy would need a fix from you to have working musicxml support. where is this documented?

[jamesjer]

Also, would that be https://github.com/leethomason/tinyxml2/issues/901? If so, let's push on tinyxml2 upstream to fix it.

[igorkorsukov]

I'm not sure if this is a correct fix or if it will work for others. It just works for us. https://github.com/musescore/MuseScore/blob/master/src/framework/global/thirdparty/tinyxml/mu_patch.h

https://github.com/musescore/MuseScore/commit/034d8a87b24e5e8aa5bb33949498ac19f4ca1e79

So we'll just keep our copy tinyxml2

[jamesjer]

I am sympathetic to pain of having a carefully tested environment, only to have people file bugs based on running in a different environment. Some projects actively discourage downstream packaging for this reason. It's easy to see what you gain with such a tactic: you decrease the number of bug reports for untested environments. What the developers of such projects often miss, though, is that they also lose something. They lose having lots of outside eyes on the code, looking for issues. Since the 4.4.0 release, you've had a number of outside people contribute diagnoses and possible solutions for problems that the MuseScore project will run into down the road. Without that, the burden of diagnosing and solving those problems later will fall entirely on the MuseScore developers. It's a tricky line to walk, for sure, and I won't criticize any decisions made on how to manage it.

One suggestion though: in the new issue template, ask if the issue was encountered in a distribution package. If the user checks that box, reply with a boilerplate message saying you don't support distribution packages, and please file a bug in that distribution's bug tracker. That puts the burden of triaging distribution-specific problems on the distribution packager instead of on you.

[igorkorsukov]

you are adding a lot of extra maintenance overhead with intree copies. e.g. last year or so there was a small bug in some container related tooling ... but because of the way of how golang works we had to touch 4+ packages because each had an intree copy.

I have a collection of my favorite programs for Windows, they are stored in the cloud, when I start working with a new device (home, work, something else), I just download them, install them or add shortcuts - they just work, like 10 years ago. As a user, this suits me more than well.

But I rarely use Windows now, because of work... And as a user, I need apps to work. And if I find an error in some program, I want to be able to simply update it to a new version. And if some program works perfectly for me, I want it to just continue working...

[darix]

FWIW: https://build.opensuse.org/ supports building for multiple distributions (deb based, rpm based, arch based) e.g. for darktable I helped them to set that everytime someone pushes to git it will automatically trigger a build of the package.

this gives them easy packages for people to verify that fixes work for them. and for the devs it gives fast feedback if their changes have unexpected consequences. If the musescore project wants a similar setup feel free to ping me.

https://build.opensuse.org/project/show/graphics:darktable:master

[igorkorsukov]

Since the 4.4.0 release, you've had a number of outside people contribute diagnoses and possible solutions for problems that the MuseScore project will run into down the road. Without that, the burden of diagnosing and solving those problems later will fall entirely on the MuseScore developers. It's a tricky line to walk, for sure, and I won't criticize any decisions made on how to manage it.

Yes, we see it and we are very grateful for it!

But I am worried that distro maintainers can see and fix obvious problems. And there are many aspects of the program's operation. And ordinary users will encounter them. And users will become testers... And they will get a negative opinion of our program. And they do not care why it happened...

[cbjeukendrup]

I suggest not to continue this discussion much longer. We've all made our points but it doesn't look like we're going to make any progress by continuing this.

AppImages/FlatPaks or OS-specific distributions all have their advantages and disadvantages, and I think we just have to live with those.

It might be a good idea indeed if experimental users can also install packages from the HEAD of our repo, similar to our Nightly Builds. If we can somehow facilitate that, we're happy to help, but if I'm not mistaken this is primarily something that distro packagers will need to work on.

[darix]

well it will need some help from people people in the musescore or to set up the required tokens to trigger packages in the OBS. and it would also be helpful if the musescore team also pays attention to the build results so they actually see if the changes break things :)

so yes the packagers can work together to prepare the package, but then we need some help from the musescore team.

Lastly I dont think that the discussion is without value. This kind of learning about the problems of the other people involved can actually be pretty useful to get an insight ... e.g. the tinyxml2 thing where you allow building with the system copy but dont warn that it might break features. Also many devs often do not have insight into the "fun" of doing the integration work in a distro and it helps to see that side too.

[saziton]

As a heavy user of "unstable" version of musescore packet maintained by @doronbehar on nixos, i'm highly aware of the possibility of problems with the app. Even if it's unstable or with some bugs, we just want our meat raw.

It also kills cross workflow between windows app that colleagues use (and me too at work) because i won't be able to open thoses files on my laptop. Please help them distribute your software the way users actually wants (and sometimes need) it.

[doronbehar]

I didn't read all the discussion here, but I always support using the latest and greatest of all dependencies, and from the system, and not bundle anything, I stated my arguments in https://github.com/musescore/MuseScore/issues/18795#issuecomment-1671400440 .

Other then that, I can confirm that https://github.com/musescore/MuseScore/pull/24247 and https://github.com/musescore/MuseScore/pull/24261 fixed the build for me - however, the top menu is not shown from some reason:

I don't have time to open an issue, so I will wait for 4.4.1 perhaps that's fixed there.

[igorkorsukov]

@darix @jamesjer Help me understand what is the best course of action.

You may know that we are also currently developing a new version of Audacity (4). And for its development, we are using the part developments from MuseScore - we call this the Muse-framework https://github.com/musescore/MuseScore/tree/master/src/framework

For this we have created a separate repository https://github.com/musescore/framework_tmp And we get it in Audacity on project configure https://github.com/audacity/audacity/blob/master/au4/CMakeLists.txt#L26 MuseScore currently has its own copy, but we are also planning use external repository, it will be the same as in Audacity 4.

i.e. when configuring the project, we will need to download the Muse framework from the network.

What would you recommend if this is a problem for you?

[darix]

ship museframework as a library an link that library into both?

[igorkorsukov]

it is too changeable, it changes almost every day

i.e. we don't have any stable version that we could distribute separately... At this stage it is simply a common part of two applications.

[darix]

1. Doing releases doesnt cost you much. Especially if it is small confined changes.
2. In the video from Martin about the "fun" of developing Musescore 4, he invited other opensource projects to also use your framework. For other projects it will also be easier if there is actually a release they can work against.

[igorkorsukov]

As I said, the code in the Muse framework changes every day. At the moment, this is not an independent project, and it is being actively developed. There are no major or minor versions. Changes in the muse framework can be breaking, something like simply renaming a component property, like this https://github.com/musescore/MuseScore/pull/24293 The application code must match the muse-framework code, for this we use tags. MuseScore and Audacity are released at different times... and therefore will definitely use different states of the muse framework. Accordingly, there is no way to add any one version of the muse framework to a distribution.