2010-05-23 6 views
3

Требование к программе, которую я пишу, заключается в том, что она должна быть в состоянии доверять конфигурационному файлу. Для этого я использую несколько алгоритмов хэширования для генерации хэша файла во время компиляции, это создает заголовок с хешами как константы.GNU Make - Зависимости от не-программного кода

Зависимости для этого довольно прямолинейные, моя программа зависит от config_hash.h, у которой есть цель, которая ее производит.

Makefile, выглядит примерно так:

config_hash.h: 
    $(SH) genhash config/config_file.cfg > $(srcdir)/config_hash.h 

$(PROGRAM): config_hash.h $(PROGRAM_DEPS) 
    $(CC) ... ... ... 

Я использую опцию -m для GCC, который отлично подходит для работы с зависимостями. Если мой заголовок меняется, моя программа перестраивается.

Моя проблема заключается в том, что мне нужно определить, был ли изменен конфигурационный файл, так что config_hash.h повторно создается. Я не совсем уверен, как объяснить такую ​​зависимость от GNU.

Я пробовал перечислять config/config_file.cfg как зависимость для config_hash.h и обеспечить целевую задачу .PHONY для файла config_file.cfg без успеха. Очевидно, я не могу полагаться на ключ -M на gcc, чтобы помочь мне здесь, поскольку файл конфигурации не является частью какого-либо объектного кода.

Любые предложения? К сожалению, я не могу опубликовать большую часть Makefile, иначе я бы просто опубликовал все это.

+1

Вы пытались запустить «make -d»? Вы получите много выходных данных (есть варианты -d, которые могут давать меньше выходных данных, но все равно быть достаточными, см. Make -help), но с config_hash.h list config_file.cfg как зависимость должна работать. Я предполагаю, что целевые имена не совпадают правильно: для вашей цели может потребоваться $ (srcdir) /config_hash.h в зависимости от config/config_file.cfg, например ... make -d должен сделать это очевидным. (Кроме того, изучение файлов .d, которые генерирует gcc -M, может также пролить свет на вещи.) – leander

ответ

5

Декларирование файл в .PHONY неправильно. Любая указанная там зависимость не будет проверяться в файловой системе. Просто перечислите его как зависимость для хэш-заголовка и оттуда.

+0

Спасибо, в этом была проблема. Я не понимал, что .PHONY отчужденные зависимости, я думал, что он должен использоваться для целей, которые на самом деле ничего не строили, даже если другие цели действительно зависят от них. –

3

Что произошло, когда вы добавили config/config_file.cfg к зависимостям config_hash.h, и почему это было не так, как вы ожидали?

Правило как

config_hash.h:config/config_file.cfg 
    $(SH) genhash $< > [email protected] 

config_hash.h бы регенерировать, если config/config_file.cfg был недавно. Ваши gcc-сгенерированные зависимости затем перекомпилируют все в зависимости от config_hash.h.

[email protected] переменная является объектом, используя это гарантирует, что вы создаете файл, который вы просили (ваш вопрос, если srcdir определено правило говорит, что будет генерировать ./config_hash.h, но на самом деле создать ./$(srcdir)/config_hash.h). Аналогично $< и $^ предоставляют первые и все предпосылки соответственно.

Я предполагаю, что у вас есть Makefile как

CPPFLAGS+=-MMD -MP 
all: 
# etc. 
config_hash.h:config/config_file.cfg 
    $(SH) genhash $< > [email protected] 
%.d %.o:%.c 
    $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $*.o $< 
%.d %.o:%.cpp 
    $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c -o $*.o $< 
-include $(wildcard *.d) /dev/null 
Смежные вопросы