Я не уверен, является ли это gmake или gcc, который я не понимаю здесь.
Я использую - MM и - опции MD генерировать правила зависимости для платформы Поблочного тестирования, которую я использую. Конкретно:
$(TEST_OBJ_DIR)/%.d: $(TEST_SRC_DIR)/%.cpp
@$(CPPC) -MM -MD $< -o $@
@sed -i -e 's|\(.*\)\.o:|$(OBJ_DIR)/\1.o $(TEST_OBJ_DIR)/\1.d $(TEST_OBJ_DIR)/\1.o:|' $@
-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}
Какие-либо идеи?
make будет автоматически создавать промежуточные файлы, если необходимо связать два правила вместе, но удалит их в конце сборки. Вы можете использовать специальную цель .PRECIOUS, чтобы предотвратить их удаление
.Одним из полезных вариантов отладки такого рода проблем является ключ -n:
make -n {TARGET}
Он покажет вам команды, которые он будет запускать, но на самом деле не будет их запускать. Это позволяет увидеть, какие правила срабатывают, но не дает дополнительных результатов, которые затрудняют диагностику проблемы.
Флаг -d отладки также может быть полезен, но обязательно запускайте его в контексте, где вы можете легко прокручивать, вы получите много вывода. Я обычно использую режим оболочки emacs, так как он имеет хорошие функции поиска и сохраняет буфер.