Interrupted make runs can't be continued, because an additional make clean is needed, so make starts from scratch again

• May 5, 2014 - 11:16

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.


In reply to by Jojo-Schmitz

I have to clarify some things:

What I made was the following:

1. git clone 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 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`
. If you want to override this, you can probably do it by running make CPUS=X with X the number you want to pass to -j.

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.

Do you still have an unanswered question? Please log in first to post your question.