2013-09-02 1 views
0

У меня есть правило в моем Makefile, который предназначен для создания символической ссылки на файл в другом каталоге:GNU сделать с VPATH: цель, которая появляется круговой, но на самом деле не должно быть

VPATH = ../source 
foo: foo 
    ln -s $< [email protected] 

Несмотря на то, Я намерен, чтобы цель разрешилась до ./foo, и зависимость для решения проблемы с ../source/foo, я понимаю, почему make видит это как круговое. Есть ли способ выразить это правило таким образом, чтобы он не был круговым?

+0

Почему бы не удалить 'foo' в качестве зависимости и изменить' $ <'to' ../ source/foo'? Я думаю, вы также можете изменить зависимость от 'foo' до' ../ source/foo' и избавиться от 'VPATH' vairable. –

+0

Изменение зависимости от '../ source/foo' и избавиться от 'VPATH', похоже, работает, хотя это означает, что мне нужно изменить что-либо еще в' Makefile', который зависит от 'VPATH'. Я надеялся избежать этого, но это не слишком много. – Anthony

ответ

0

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

foo: 
    ln -sf ../source/[email protected] 

Однако, это не будет работать правильно, если вы по-прежнему нужны ваша VPATH для других целей. Если это так, то мне кажется, самый простой способ будет игнорировать VPATH для этого правила, используя абсолютный путь:

VPATH := ../source 
$(CURDIR)/foo: 
    ln -sf ../source/$(@F) 

Наконец, если файл ../source/foo также является мишенью, которая генерируется Make, затем может быть, лучше всего было бы:

VPATH := ../source 

.SECONDEXPANSION: 
$(CURDIR)/foo: | ../source/$$(@F) 
    ln -sf $| 

Обратите внимание, что мы не в зависимости от изменений предпосылки здесь, только о существовании этого.

Кстати, причина, по которой я использую опцию -f, заключается в том, что Make должен поддерживать -B. Этот вариант не будет работать, если вы не используете здесь -f.

0

Я думаю, что вы здесь пытаетесь подпасть под категорию «VPATH abuse».

Мой опыт неоднократно указывал на меня в сторону мантры «явный лучше, чем неявный», и это одна из причин. В отличие от утверждений в GNU make Manual, мой опыт заставил меня поверить, что в более крупных и более сложных проектах вам нужно быть более эксплицитности, а не меньше, поскольку размер затрудняет поиск файлов, если только их путь явный.

Я также считаю, что большая часть использования VPATH проистекает из использования рекурсивного make, где вы не строите деревья зависимостей; правильно напишите свою систему сборки, и вам просто не нужен VPATH.

На схожую тему, я твердо верит в только указать один или два -I каталогов: верхний уровень, src/ и include/ каталогов и сделать всех inclussions относительно этих путей. Опять же, по более крупным, более сложным проектам, определение #include "my/really/cool/thing.h" является настолько информативным, чем просто #include "thing.h".

Это говорит о том, что я открыт для использования VPATH для библиотек, особенно для системных библиотек, поскольку вы можете использовать синтаксис -lfoo, но я бы не хотел использовать его в качестве общего правила, поскольку он может угрожать сборке воспроизводимости.

Смежные вопросы