Am Freitag, 18. August 2017 19:15 CEST, Lasconic <[email protected]> schrieb:
> Werner and I build several time daily from the command line. Werner on > Linux and I, on MacOSX. > > Also for every commit on the 2.2 and master branch, Travis runs on the > command line on Ubuntu 14.04 > https://travis-ci.org/musescore/MuseScore/jobs/265942105 Wow, gcc-4.6, that's ancient. Even Debian Stable is at 6.3 by now. Do you do a "clean" build or do you just recompile. Once all.h got copied to the binary directory the next compile will find it. > So there is something very particular in your setting. I just did a fresh checkout of 2.2, after a run of cmake selecting the makefile backend I run make, which pretty soon aborts: $ /usr/local/src/MuseScore/build2.2$ make [ 0%] Generating mscore.1.gz 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 I then ran make in debugging/verbose mode which did not reveal more information. >From all I can tell the buildprocess first runs the 'manpages' target and then tries to run the 'qtsingleapp_autogen' target which of course is doomed to fail since that CMakeLists.txt expicitly lists '${PROJECT_BINARY_DIR}/all.h' as a dependency but that file hasn't been copied to '${PROJECT_BINARY_DIR}' yet. Running the 'mops1' target manually does fix this problem. So there definitely seems to be a missing dependency declaration, which seems stange since the CMakeLists.txt files in all third-party subprojects do contain ADD_DEPENDENCY declarations. On further investigation it turns out that none of the subprojects can be build by invoking the toplevel makefile with 'make <subproject>' even so these subprojects are listed as valid target when running 'make help'. This clearly shows that the dependency on mops1 doesn't propagate. After having a closer look at the way the thirdparty cmake files are set up I think I found the culprit. Those files add all.h to the source file lists, which I think is wrong. Removing 'all.h' from the sources list seems to fix the problem - now building the qsingleapp target triggers the build of 'all.h'. BTW: if you use cmake' ninja backend you'll see the following warning: $ ninja all ninja: warning: multiple rules generate all.h. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] Without further investigation I'd say this might be the reason the current gcc does ignore the pre-compiled headers. Thank's for your patience RalfD ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
