Зависимости Makefile от нескольких файлов

Question

Я создал Makefile для модульных тестов, который использует GCC с аргументами для создания профилирующих файлов (gcno) во время компиляции. Вот similified его часть, где компиляции и компоновки имеет место:

UTEXE  = $(UTOBJSDIR)\$(UTUNIT).exe 
UTOBJS  = $(UTUUTSRC:.c=.o) $(UTUTSRC:.c=.o) $(UTCSRC:.c=.o) 
UTOBJSFULL = $(addprefix $(UTOBJSDIR)\,$(UTOBJS)) 
UTOBJSGCNO = $(addprefix $(UTOBJSDIR)\,$(UTOBJS:.o=.gcno)) 

$(UTOBJS): %.o: %.c $(UTMAKEDEP) 
    $(call report,Compiling $(*F).c) 
    $(MKDEP) $(MKDFLAGS) -o.o -f$(UTOBJSDIR)\$(*F).dep $(subst /,\,$<) 
    $(CC) -c $(CFLAGS) $(subst /,\,$<) -o $(UTOBJSDIR)/$@ 

$(UTOBJSGCNO): $(UTOBJS) $(UTMAKEDEP) 

utbuild: $(UTEXE) $(UTOBJSGCNO) $(UTOBJS) $(UTMAKEDEP) 

$(UTEXE): $(UTOBJSGCNO) $(UTOBJS) $(UTMAKEDEP) 
    $(call report,Linking to $(UTUNIT).exe) 
    $(LINK) $(UTOBJSFULL) $(LNKFLAGS) -o $(UTEXE) 

Он собирает все объектные и профильные файлы и ссылки вместе бинарный файл. Однако, когда я удаляю файл профиля (gcno) и снова вызываю «utbuild», он не будет повторно компилироваться для восстановления файла .gcno. Он пытается сделать ссылку снова, потому что gcno является для него префиксным, но он не выполняет компиляцию.

Я не знаю, как назвать этот случай, так что не удалось найти решение из Интернета. В основном один рецепт создает два файла, и я не знаю, как написать правило, которое повторно запускает рецепт, даже когда нужно восстановить только один файл.

Буду признателен за ссылки или подсказки.

Answer 1

Правильный ответ, на мой взгляд, есть, не удаляет файлы .gcno. Если вам нужно «очистить», используйте make clean, но не просто удаляйте файлы.

«Сборка» - это конечный автомат со всеми файлами, составляющими «состояние». Не коррумпируйте государство!

Некоторые люди говорят, что вы должны удалять произвольные файлы, и сборка должна восстанавливаться. Мой ответ: если вы повредите файл .o вручную, скажем, добавьте 0 и 1, что сделает его непригодным (спасибо user3629249 за указание, что нужно уточнить, что я говорю о коррупции, а не преднамеренное редактирование). Должна ли сборка также оправиться от этого? Очевидно, что никакая система сборки в мире не восстановится, если вы коснетесь файла .o таким образом. Тогда зачем разрешать удаление файла, но не разрешать его изменять? Где вы проводите линию?

Проще говоря, любая коррупция не должна допускаться. Используйте только make clean, или еще лучше, напишите свой Makefile правильно, поэтому вам не нужно очищать период.

---

Весь Makefile имеет ряд проблем, вот как это должно выглядеть (я предполагаю, что это на Windows/DOS):

.SUFFIXES: 
UTEXE := $(UTOBJSDIR)\$(UTUNIT).exe 
UTOBJSFULL := $(addprefix $(UTOBJSDIR)\,$(subst /,\, $(UTUUTSRC:.c=.o) $(UTUTSRC:.c=.o) $(UTCSRC:.c=.o))) 
UTOBJSGCNO := $(UTOBJSFULL:.o=.gcno) 

.PHONY: utbuild all 
all: utbuild 
utbuild: $(UTEXE) $(UTOBJSGCNO) $(UTMAKEDEP) 

$(UTOBJSGCNO): %.gcno: %.o $(UTMAKEDEP) ; 

.SECONDARY: %\. 
%\.: Makefile 
    mkdir $* 

.SECONDEXPANSION: 

$(UTOBJSFULL): $(UTOBJSDIR)\%.o: %.c $(UTMAKEDEP) | $$(@D)\. 
    $(call report,Compiling $<) 
    $(MKDEP) $(MKDFLAGS) -o.o -f$(UTOBJSDIR)\$(*F).dep $< 
    $(CC) -c $(CFLAGS) $< -o $@ 

$(UTEXE): $(UTOBJSFULL) $(UTMAKEDEP) | $$(@D)\. 
    $(call report,Linking to $(@F)) 
    $(LINK) $(UTOBJSFULL) $(LNKFLAGS) -o $@ 

Answer 2

спасибо за все комментарии. Я пробовал no-op ";" и ": =" с тем же результатом.

Думаю, мне нужно сделать один шаг назад и объяснить, почему я задал этот вопрос. Речь идет не только об удалении или не удалении gcno-файлов вручную, это общее понимание того, как писать такой Makefile, который восстанавливает любой отсутствующий или устаревший файл. Мой файл Makefile имеет похожие случаи в нескольких местах, и он использует параллельную сборку, поэтому, когда какой-то файл пропадает, он дает много странных ошибок. Обычно он решается «чистым» и «все», но мне бы хотелось, чтобы Makefile был идеальным и отлично справлялся с недостающими файлами.

Как вышеприведенный пример не так ясен без остальной части Makefile, тогда я сделал новый простой тест.

привет.с

#include <stdio.h> 

int main() 
{ 
    printf("Hello world\n"); 
} 

Makefile

CCDIR = C:\tools\MinGW 
CCBINDIR = $(CCDIR)\bin 
CCINCDIR = $(CCDIR)\include;$(CCDIR)\lib\gcc\mingw32\4.8.1\include 
CCLIBDIR = $(CCDIR)\lib;$(CCDIR)\lib\gcc\mingw32\4.8.1 

# Overcome "missing dll file" messages on Windows 
CC  = set PATH=%PATH%;$(CCBINDIR)& $(CCBINDIR)\gcc.exe 
LINK  = set PATH=%PATH%;$(CCBINDIR)& $(CCBINDIR)\gcc.exe 

# Compile and link for code coverage 
CFLAGS = -fprofile-arcs -ftest-coverage -g3 -O0 $(addprefix -I,$(CCINCDIR)) 
LNKFLAGS = -fprofile-arcs -ftest-coverage -static -static-libgcc $(addprefix -L,$(CCLIBDIR)) 

OBJECTS = hello.o 
EXE  = hello.exe 

$(OBJECTS): %.o: %.c 
    $(CC) -c $(CFLAGS) $(subst /,\,$<) -o $@ 

$(EXE): $(OBJECTS) 
    $(LINK) $(OBJECTS) $(LNKFLAGS) -o $(EXE) 

build: $(EXE) 

"сделать сборку" создает следующие файлы:

• hello.o
• hello.gcno
• hello.exe

Теперь, если я удалить «hello.gcno» и запустить воссоздам он говорит мне:

mingw32-make: Nothing to be done for 'build'. 

Цель состоит в том, чтобы обновить Makefile так, что делают воссоздает «hello.gcno». Вероятно, он снова заново создаст «hello.o» и «hello.exe» во время этого процесса, но это не проблема.

Редактировать: Просто, чтобы быть ясным: в реальном Makefile мне действительно нужны файлы .gcno. Это не просто дополнительная информация или что-то, что можно избежать или сделать необязательным. Makefile создает исполняемые файлы единичного теста, запускает их и выполняет gcov для генерации информации о покрытии кода, а gcovr создает отчет обо всех файлах .gcov. Если файл .gcno отсутствует, он не будет работать. Кроме того, поскольку это параллельная сборка, зависимости должны быть абсолютно правильными, чтобы избежать некоторого процесса, начинающегося ранее, и это сложно, потому что в отчете покрытия есть зависимости, поступающие из двух «ветвей» - .gcno-файлов из этапа компиляции и .gcda-файлов с этапа выполнения. Вот почему мне нужно, чтобы это было правильно.