Удалять файлы зависимостей

Я не уверен, что это gmake или gcc, что я не понимаю здесь.

Я использую опции -MM и -MD для генерации правил зависимостей для используемой структуры модульного тестирования. В частности:

$(TEST_OBJ_DIR)/%.d: $(TEST_SRC_DIR)/%.cpp
  @$(CPPC) -MM -MD $< -o [email protected]
  @sed -i -e 's|\(.*\)\.o:|$(OBJ_DIR)/\1.o $(TEST_OBJ_DIR)/\1.d $(TEST_OBJ_DIR)/\1.o:|' [email protected]

-include $(TEST_DEP_FILES)

Когда я запускаю make, после того, как все двоичные файлы связаны (правильно), я вижу следующую дополнительную (необъяснимую) строку перед выполнением выходов

rm test/obj/dice.d test/obj/regex.o test/obj/inventoryContainer.d test/obj/color-string.d test/obj/dice.o test/obj/inventoryContainer.o test/obj/color-string.o test/obj/regex.d

Откуда приходит команда rm? Единственное место - где угодно - то, что у меня есть команда rm в моем make файле, находится в чистой директиве

test-clean:
  rm -f $(TEST_BIN_FILES)
  rm -f $(TEST_OBJ_DIR)/*.{a,d,o}

Любые идеи?

Ответ 1

make автоматически создаст промежуточные файлы, если необходимо объединить два правила вместе, но они удалят их в конце сборки. Вы можете использовать . PRECIOUS специальную цель, чтобы предотвратить ее удаление.

Ответ 2

Одним из полезных вариантов для отладки таких проблем является ключ -n:

make -n {TARGET}

Он покажет вам команды, которые он будет запускать, но фактически не запускает их. Это позволяет вам видеть, какие правила увольняются, но не дает вам дополнительного вывода, который затрудняет диагностику проблемы.

Флаг -d-debug также может быть полезен, но обязательно запустите его в контексте, где вы можете легко прокручивать, вы получите много выходных данных. Обычно я использую режим оболочки emacs, так как он имеет хорошие функции поиска и сохраняет буфер.