Потому что цель может быть построена неправильно. В следующий раз, когда вы make
проект, он попытается восстановить цель. Если файл не был удален, make
не сможет узнать, что что-то пошло не так. make
не может знать, что сбой произошел из-за теста, а не процесса, который строит цель.
Желательно ли это поведение в вашем случае, зависит от характера тестов. Если вы планируете исправить тест, чтобы он не вызывал Bus error
, удаление цели не имеет большого значения. Если вы хотите использовать цель для отладки позже, вам нужно внести изменения в процесс make.
Один из способов не удалять цели - использовать цель .PRECIOUS
.
Другое может быть:
$(tests): %: %.c
gcc -o $@ $(testflags) $<
-$@
Не проверено, но документация указывает, что цель не будет удалена:
Когда происходит ошибка, о которой make не было сказано игнорировать, это означает, что текущая цель не может быть корректно переделана, как и любая другая, которая зависит от нее прямо или косвенно. Для этих целей дальнейшие команды не будут выполняться, поскольку их предварительные условия не были достигнуты.
и
Обычно при сбое команды, если она вообще изменила целевой файл, файл поврежден и не может быть использован или, по крайней мере, не полностью обновлен. Тем не менее, отметка времени файла говорит о том, что он обновлен, поэтому при следующем запуске make не будет пытаться обновить этот файл. Ситуация такая же, как когда команда убита сигналом; см. Прерывания. Таким образом, в общем случае правильное решение - удалить целевой файл, если после начала изменения файла не удается выполнить команду. make сделает это, если в качестве цели появится .DELETE_ON_ERROR. Это почти всегда то, что вы хотите сделать, но это не историческая практика; поэтому для совместимости вы должны явно запросить его.