Broken build (No rule to make target 'all.h')
Hello,
I just tried to compile a pristine version of MuseScore from a fresh git checkout (Branch 2.1, build on Debian in an OOT CMake build).
CMake configuration works fine but make will abort with the following error:
/usr/local/src/NewScore/build64$ make
Man pages have been compressed ready for installation.
Creating symlink alias for man pages.
Symlink alias: musescore.1.gz -> mscore.1.gz
[ 0%] Built target manpages
make[2]: *** No rule to make target 'all.h', needed by 'thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen'. Stop.
CMakeFiles/Makefile2:8789: recipe for target 'thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen.dir/all' failed
make[1]: *** [thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2
Comments
I've never tried building from the command line, but my guess is you still need to get the cmake configuration right, and in this context, that probably means somehow telling the build unequivocably whether or not you want precompiled headers. Sounds like maybe it is trying to use them but you haven't built them yet.
In reply to I've never tried building… by Marc Sabatella
I've never tried building from the command line
Oh, wow! I allways build from the command line using CMake.
I have configured the cmake options (the same configuration options as always). That dependency on 'all.h' is declared in
thirdparty/singleapp/src/CMakeLists.txt, and the code to copy that file into the right place is inCMakeLists.txt.That really smells like some broken dependeny sneaked in ...
In reply to I've never tried building… by rmattes
There is a Makefile in the build root directory and it will call CMake properly.
https://musescore.org/en/developers-handbook/compilation/compile-instru…
is probably almost up to date for a 2.1 build.
In reply to There is a Makefile in the… by [DELETED] 5
I know about that Makefile. But, as I wrote, I'm doing OOT-builds (also known out of source builds), hence
need to set up my own build directories (I'm doing both 32 and 64bit binary builds) and I usually use CMake's
ninja backend for the Linux builds.
I'm pretty shure I did call cmake properly, at least my settings pretty much correspond to the Makfile's defaults. N.B.: isn't it kind of strange to run a makefile to run cmake to generate a makefile to then run make on that ? That file looks as if it suffered from a bit of bbitrod (the 'unix' target looks strange).
In my (very humble) experience, when clean checkouts don't build that's often a sign for weakly defined dependencies. To get back to the start of this thread: why doesn't all.h get copied to the compilation directory?
And, since it's not a generated file (after all, it's checked into git), why isn't it placed into either mscore or libmscore?
BTW, both the makefile and ninja builds complain about the precomiled headers not being useable because of missing STRICT_ANSI declaration.
In reply to I know about that Makefile… by rmattes
why doesn't all.h get copied to the compilation directory?
I don't know but it should per https://github.com/musescore/MuseScore/blob/2.1/CMakeLists.txt#L573
why isn't it placed into either mscore or libmscore?
Not sure why it would be. Both mscore and libmscore depends on the same all.h
both the makefile and ninja builds complain about the precomiled headers not being useable because of missing STRICT_ANSI declaration
That's a problem with the compiler, not the build system I believe. We try to compile the precompiled header with the same flags than the rest of MuseScore. See https://github.com/musescore/MuseScore/blob/2.1/build/CreatePrecompiled…
In reply to why doesn't all.h get copied… by [DELETED] 5
>> why isn't it placed into either mscore or libmscore?
> Not sure why it would be. Both mscore and libmscore depends on the same all.h
all.h is needed in basically every directory, so that would be insane effort to change that.
>> why doesn't all.h get copied to the compilation directory?
> I don't know but it should per https://github.com/musescore/MuseScore/blob/2.1/CMakeLists.txt#L573
That dependency is never called, at least not with PCH disabled.
The second hunk of https://sources.debian.net/patches/musescore/2.1.0%2Bdfsg1-0.2/02-globa… seems to fix it (at least it made the build work under Debian). Basically, it’s an ordering issue. But then, I don’t really know cmake, I just searched around for possible solutions, incrementally increasing my understanding of the problem.
Just wondering, are you running CMake 3.9?
I managed to get it to build by removing all references to ${PROJECT_BINARY_DIR}/all.h and ${PCH} in the various CMakeLists.txt littered around the source tree, except for the following files: