Interrupted make runs can't be continued, because an additional make clean is needed, so make starts from scratch again
I'm running Fedora Linux F20/x86_64. I downloaded the source mscore-1.3.tar.bz2, unpacked it, switched to mscore-1.3 and run gmake. So far so good. But if the make process is interrupted or killed for some reasons, the whole make process has to be repeated. A continuation is impossible because a second make run complains with:
"build directory does already exist, please remove first with 'make clean'"
If I run make clean, all object files will be removed, and the next make run starts from scratch.
This is very unusual in LINUX/UNIX because normally broken make's can be continued without any problem.
Comments
Not sure why you'd want to compile 1.3 yourself, rather then the current in-development Version, for which you'd get the sources from GitHub and the instructions from the developers' handbook
There won't be further fixes to 1.x, not even to its build process.
In reply to Not sure why you'd want to by Jojo-Schmitz
Same problems if using the actual source from git. So my question: why interrupted builds need to be cleaned before re-running the make?
Joachim Backes
In reply to Same problem with the git mscore sources by Joachim Backes
No idea, they don't need that under Windows
Is it doing this on a 'make release' (or a plain 'make', which should be doing the same thing) and/or 'make debug' or 'make install'/'make installdebug'?
In the Makefile I can see it will be doing this on a 'make unix', which to my understanding isn't what you should be using.
In reply to No idea, they don't need that under Windows by Jojo-Schmitz
I have to clarify some things:
What I made was the following:
1. git clone git://github.com/musescore/MuseScore.git
2. cd MuseScore
3. gmake revision
4. Kill gmake and rerun gmake # multiple times
I interrupted the "gmake" several times. During the last trial, I killed the build process at 90%. Then I made an additional new gmake (without "make clean" - this seems to run properly with the git version), and the gmake process was resumed at 55%. This percent values did not change during this make run, but suddendly the make run finished and switched to 100%.
So my impression:
1. In the git version, I don't have to run "make clean" if rerunning make after interruption
2. The percent values of the make process can't be fully understood.
3. The make process always runs with all CPU's my box has, independent from the the -j value I gave the gmake command (number processes to use).
In reply to weird interrupted and restarted build process? by Joachim Backes
In Makefile:
CPUS = `grep -c processor /proc/cpuinfo`
...
make -j ${CPUS};
This got to be the reason it uses all your CPUs
The percentage display I think stems from cmake, no idea where that gets it from.
In reply to weird interrupted and restarted build process? by Joachim Backes
When you use the top level makefile, it runs cmake first and then run make on the cmake-generated makefiles. As you can see if you edit the main Makefile, the -j option is hard coded in there and get the number of CPUS via
CPUS = `grep -c processor /proc/cpuinfo`
Regarding the test of the the presence of the build.release directory, I'm not sure why it's like this. I removed it for the windows and mac builds but I didn't do it on Linux because I thought it was done on purpose.