Closed gucio321 closed 3 months ago
Hm... I don't immediately have an idea what causes this (since I'm not experiencing this myself). Things I can think of:
# in the folder where you checked out the source code
mkdir build.release # or build.debug, or whatever actually; can even be `../.../myFavouriteBuildFolder`
cd build.release # that same build folder
cmake .. # the path from the build folder to the folder where you checked out the source code
make # in the build folder
Of course, after doing an in-source build, your whole source folder got cluttered with build artefacts, so I'd suggest either using Git to discard these files, or deleting and re-cloning/downloading the source code.
well, I forgot about these in-source builds are not allowed by cmake (why?!)
I did rm -rf *;git reset --hard origin/master
. This should have cleaned up my folder a bit :smile:
then I did cmake -Bbuild
.
Here I attach output of make -j12
:
I see no more errors...
also update: now I'm on more current master (than in OP). 723753443b4406902440ad942e574d9166acf074
Weird. So basically the same problem. What if you try using the Ninja
generator instead of make
? Install Ninja (may be called ninja-build
in your package manager) and then do cmake -GNinja …
.
just crashes immediately
[build (0) ]$ ninja
[0/2] Re-checking globbed directories...
ninja: error: 'src/framework/global/CMakeFiles/muse_global.dir/cmake_pch.hxx.gch', needed by 'src/framework/global/CMakeFiles/muse_global.dir/Unity/unity_5_cxx.cxx.o', missing and no known rule to make it
@gucio321 Sorry that I didn't reply anymore but I'm afraid I'm out of suggestions. I've also asked a colleague and he also didn't have ideas, other than that the problem may go away when just retrying. Perhaps updating CMake or Ninja can help... or the problem will go away at some point as a result of changes to the codebase... who knows. What versions of CMake and Ninja are you using?
I'm on fedora so I suppose pretty new
cmake version 3.28.2
1.11.1
I see I didin't do that before so let me post cmake output:
cmake -Bbuild -GNinja .
Hm... I don't immediately see anything enlightening there.
I do notice that you are using Qt 6.7, while MuseScore currently wants 6.2. I can't imagine it makes a huge difference for this issue, but you never know.
no idea... I don't want to mess up with system libraries so I'd prefer to stay on v6.7
This one seems similar https://gitlab.kitware.com/cmake/cmake/-/issues/25650
ok... I used -DMUE_COMPILE_USE_UNITY=OFF
and it suddenly worked, but why?
I need to do a few more tests before I can say I'm 100% sure I identified the but I think its most likely that this issue is gone now (im on 61% of cmake atm)
This one seems similar https://gitlab.kitware.com/cmake/cmake/-/issues/25650
Suspiciously similar, one might even say! That issue states that it started happening since CMake 3.28.2, and the right sidebar suggests that it has been fixed in CMake 3.28.3. So it's worth trying to update (or waiting until your distribution updates it...)
Why -DMUE_COMPILE_USE_UNITY=OFF
works? That disables unity build, and the issue you linked says that the problem arises specifically when both precompiled headers and unity build are enabled.
Disabling unity build is something you can indeed do. In case you didn't know, unity build means that multiple .cpp files are concatenated into big "unity" files and those big unity files are actually compiled, rather than each individual .cpp file separately.
This speeds up the initial build time, because there are less so-called "translation units" to compile and link. However, depending on your computer, it might slow down incremental builds, because if one cpp file is modified, the whole unity file containing that cpp file needs to be recompiled, instead of only that cpp file. So, whether you enable or disable it is up to you, and what's faster in the long run depends completely on what kind of things you often do and on your system.
There is one caveat: when a #include or a using namespace
is missing in a cpp file, it might still compile when using unity build, because the cpp files are simply concatenated, so if another cpp file that lands in the same unity file does contain that #include
or using namespace
, it still compiles. But when not using unity build, it doesn't of course. Our CI does have unity build enabled, and most developers also use it (because that's the default), so hardly anyone ever tests non-unity build, so it is possible that that is currently broken. Therefore, disabling unity build is in practice not bound to be successful.
Ok, so I'll disable unity build for now and wait for new cmake.
But now I'm getting the following:
types/geometry.h:450:24: note: remove the ‘< >’
avigableappmenumodel.cpp: In function ‘QSet<int> possibleKeys(QKeyEvent*)’:
avigableappmenumodel.cpp:42:47: error: conversion from ‘QList<QKeyCombination>’ to non-scalar type ‘QList<int>’ requested
possibleKeys(correctedKeyEvent);
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
avigableappmenumodel.cpp: In function ‘QSet<int> possibleKeys(const QChar&)’:
avigableappmenumodel.cpp:50:47: error: conversion from ‘QList<QKeyCombination>’ to non-scalar type ‘QList<int>’ requested
possibleKeys(&fakeKey);
~~~~~~~~~~~~^~~~~~~~~~
That looks like a Qt 6.7 issue.
To get Qt 6.2.4 in an easy way without affecting anything of your system, you could download the build that we use on CI. See https://s3.amazonaws.com/utils.musescore.org/Qt624_gcc64.7z
I see :smile: I love backwards compatibility at qt... Are there any plans at musescore to update to 6.7?
Not anytime soon, because it requires dropping support for quite some macOS versions and it causes some strange blocking bugs that are difficult to debug.
ok, I've downloaded the file, how thould I use it now?
This is what the CI scripts do with it:
# Get newer Qt (only used cached version if it is the same)
qt_version="624"
qt_dir="$BUILD_TOOLS/Qt/${qt_version}"
if [[ ! -d "${qt_dir}" ]]; then
mkdir -p "${qt_dir}"
qt_url="https://s3.amazonaws.com/utils.musescore.org/Qt${qt_version}_gcc64.7z"
wget -q --show-progress -O qt.7z "${qt_url}"
7z x -y qt.7z -o"${qt_dir}"
rm qt.7z
fi
export PATH="${qt_dir}/bin:\${PATH}"
export LD_LIBRARY_PATH="${qt_dir}/lib:\${LD_LIBRARY_PATH}"
export QT_PATH="${qt_dir}"
export QT_PLUGIN_PATH="${qt_dir}/plugins"
export QML2_IMPORT_PATH="${qt_dir}/qml"
I.e. download, extract to an arbitrary location, put the /bin
subfolder of that location in $PATH (I think the other env variables are not really necessary).
Alternatively to modifying $PATH, it might be possible to do -DCMAKE_PREFIX_PATH=${qt_dir}/bin
.
I will close this issue now, since it has been confirmed to be a (resolved) CMake bug and not a MuseScore problem. But if you have any further questions, still feel free to comment on this thread!
@cbjeukendrup now I'm getting this
/home/me/git/musescore/src/framework/draw/types/geometry.h:450:24: note: remove the ‘< >’
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.h:136:40: error: ‘Measure’ has not been declared
136 | bool readLv(pugi::xml_node lvNode, Measure* measure);
| ^~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp: In member function ‘bool mu::iex::mei::MeiImporter::readMRpt(pugi::xml_node, mu::engraving::Measure*, int, mu::engraving::Fraction&)’:
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1852:27: error: cannot convert ‘mu::engraving::MeasureRepeat*’ to ‘mu::engraving::EngravingItem*’
1852 | Convert::colorFromMEI(measureRepeat, meiMRpt);
| ^~~~~~~~~~~~~
| |
| mu::engraving::MeasureRepeat*
In file included from /home/me/git/musescore/src/importexport/mei/internal/meiimporter.h:33:
/home/me/git/musescore/src/importexport/mei/internal/meiconverter.h:182:56: note: initializing argument 1 of ‘static void mu::iex::mei::Convert::colorFromMEI(mu::engraving::EngravingItem*, const libmei::Element&)’
182 | static void colorFromMEI(engraving::EngravingItem* item, const libmei::Element& meiElement);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1853:17: error: cannot convert ‘mu::engraving::MeasureRepeat*’ to ‘const mu::engraving::EngravingItem*’
1853 | m_uids->reg(measureRepeat, meiMRpt.m_xmlId);
| ^~~~~~~~~~~~~
| |
| mu::engraving::MeasureRepeat*
/home/me/git/musescore/src/importexport/mei/internal/meiconverter.h:375:46: note: initializing argument 1 of ‘void mu::iex::mei::UIDRegister::reg(const mu::engraving::EngravingItem*, const std::string&)’
375 | void reg(const engraving::EngravingItem* item, const std::string& meiUID) { m_uids[reinterpret_cast<uintptr_t>(item)] = meiUID; }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1854:18: error: invalid use of incomplete type ‘class mu::engraving::MeasureRepeat’
1854 | measureRepeat->setTrack(track);
| ^~
In file included from /home/me/git/musescore/src/engraving/dom/engravingitem.h:44,
from /home/me/git/musescore/src/engraving/dom/durationelement.h:26,
from /home/me/git/musescore/src/engraving/dom/chordrest.h:30,
from /home/me/git/musescore/src/engraving/dom/articulation.h:28,
from /home/me/git/musescore/src/importexport/mei/internal/meiconverter.h:26:
/home/me/git/musescore/src/engraving/dom/engravingobject.h:114:7: note: forward declaration of ‘class mu::engraving::MeasureRepeat’
114 | class MeasureRepeat;
| ^~~~~~~~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1855:18: error: invalid use of incomplete type ‘class mu::engraving::MeasureRepeat’
1855 | measureRepeat->setTicks(measure->ticks());
| ^~
/home/me/git/musescore/src/engraving/dom/engravingobject.h:114:7: note: forward declaration of ‘class mu::engraving::MeasureRepeat’
114 | class MeasureRepeat;
| ^~~~~~~~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1856:18: error: invalid use of incomplete type ‘class mu::engraving::MeasureRepeat’
1856 | measureRepeat->setNumMeasures(1);
| ^~
/home/me/git/musescore/src/engraving/dom/engravingobject.h:114:7: note: forward declaration of ‘class mu::engraving::MeasureRepeat’
114 | class MeasureRepeat;
| ^~~~~~~~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1858:18: error: cannot convert ‘mu::engraving::MeasureRepeat*’ to ‘mu::engraving::EngravingItem*’
1858 | segment->add(measureRepeat);
| ^~~~~~~~~~~~~
| |
| mu::engraving::MeasureRepeat*
In file included from /home/me/git/musescore/src/engraving/dom/segmentlist.h:26,
from /home/me/git/musescore/src/engraving/dom/measure.h:33,
from /home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:46:
/home/me/git/musescore/src/engraving/dom/segment.h:163:14: note: initializing argument 1 of ‘virtual void mu::engraving::Segment::add(mu::engraving::EngravingItem*)’
163 | void add(EngravingItem*) override;
| ^~~~~~~~~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp: In member function ‘bool mu::iex::mei::MeiImporter::readControlEvents(pugi::xml_node, mu::engraving::Measure*)’:
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:2195:65: error: cannot convert ‘mu::engraving::Measure*’ to ‘int*’
2195 | success = success && this->readLv(xpathNode.node(), measure);
| ^~~~~~~
| |
| mu::engraving::Measure*
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.h:136:49: note: initializing argument 2 of ‘bool mu::iex::mei::MeiImporter::readLv(pugi::xml_node, int*)’
136 | bool readLv(pugi::xml_node lvNode, Measure* measure);
| ~~~~~~~~~^~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp: At global scope:
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:2542:6: error: no declaration matches ‘bool mu::iex::mei::MeiImporter::readLv(pugi::xml_node, mu::engraving::Measure*)’
2542 | bool MeiImporter::readLv(pugi::xml_node lvNode, Measure* measure)
| ^~~~~~~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.h:136:10: note: candidate is: ‘bool mu::iex::mei::MeiImporter::readLv(pugi::xml_node, int*)’
136 | bool readLv(pugi::xml_node lvNode, Measure* measure);
| ^~~~~~
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.h:71:7: note: ‘class mu::iex::mei::MeiImporter’ defined here
71 | class MeiImporter
| ^~~~~~~~~~~
make[2]: *** [src/importexport/mei/CMakeFiles/iex_mei.dir/build.make:165: src/importexport/mei/CMakeFiles/iex_mei.dir/internal/meiimporter.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:8916: src/importexport/mei/CMakeFiles/iex_mei.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
@gucio321
for fix this issue you should add engraving::
to Measure*
in meiimporter.h line 136
@Eism why is this necessary? Is it a bug in musescore or I should build it somehow else?
Yes, that is probably a MuseScore issue, resulting from what I mentioned here about (non-)unity builds: https://github.com/musescore/MuseScore/issues/22979#issuecomment-2153496262
so shall we re-open this issue or create a new one? imo unity build should either be fixed or non-unity build should be denied.
I don't think we need an issue for it, but feel free to create a pull request with the required changes. There are probably a few more (changing Point
to muse::Point
in some header file)
i'm not really familiar with c++, but I can try with some PR one more thing: what should be here?
/home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:1858:18: error: cannot convert ‘mu::engraving::MeasureRepeat*’ to ‘mu::engraving::EngravingItem*’
1858 | segment->add(measureRepeat);
| ^~~~~~~~~~~~~
| |
| mu::engraving::MeasureRepeat*
In file included from /home/me/git/musescore/src/engraving/dom/segmentlist.h:26,
from /home/me/git/musescore/src/engraving/dom/measure.h:33,
from /home/me/git/musescore/src/importexport/mei/internal/meiimporter.cpp:46:
/home/me/git/musescore/src/engraving/dom/segment.h:163:14: note: initializing argument 1 of ‘virtual void mu::engraving::Segment::add(mu::engraving::EngravingItem*)’
163 | void add(EngravingItem*) override;
| ^~~~~~~~~~~~~~
Perhaps it's more efficient if I take a look at it myself tonight, because after I figure out what needs to be done, it's trivial to do that myself.
I see 😄 I love backwards compatibility at qt... Are there any plans at musescore to update to 6.7?
In fairness, at least the QKeyMapper error is because MuseScore is using a private API that has no backwards compatibility. In fact (according to its header...):
//
// W A R N I N G
// -------------
//
// This file is not part of the Qt API. It exists purely as an
// implementation detail. This header file may change from version to
// version without notice, or even be removed.
//
// We mean it.
(And apparently, they did mean it. The private QKeyMapper::possibleKeys
was changed to return QList<QKeyCombination>
instead of QList<int>
in QT change 504447 last October.)
In fairness, at least the QKeyMapper error is because MuseScore is using a private API that has no backwards compatibility. In fact (according to its header...)
Yeah, you are right Created thech debt https://github.com/musescore/MuseScore/issues/23988
+1 I was able to work around the QKeyMapper
change pretty easily, and pretty cleanly if I do say so myself, but that doesn't mean it's safe to continue to rely on that kind of stuff. Private APIs should be used very sparingly and only as an absolute last resort, as they tie your code way too closely to a particular version of the dependency.
(I was looking at MuseScore's use of KDDockWidgets as well, for Fedora, in hopes of switching over to using a system build of KDDW 2.1 now that it's out. (And builds with both QtWidgets and QtQuick enabled by default & automatically.)
But, there again, MuseScore is not only using include paths that point directly into the bundled thirdparty/kddockwidgets/src/
tree, but it's #including
private headers that exist in the bundled version, but don't at all in 2.0+. All of the same public headers are there, but the private ones have all been shuffled around, as is their wont and their right.)
Issue type
Other type of issue
Bug description
I run
cmake .
and thenmake
and it crashes:Steps to reproduce
Screenshots/Screen recordings
No response
MuseScore Version
current (Sun May 26 11:11:00 AM CEST 2024) master
Regression
Yes, this used to work in a previous version of MuseScore 4.x
Operating system
fedora linux 40
Additional context