Как мне указать, с чего начать в графе зависимостей, который не имеет фиксированной начальной точки - PullRequest
0 голосов
/ 25 февраля 2012

Я использую цепочку инструментов, которая больше похожа на сеть. Существует множество альтернативных начальных точек, все из которых приводят к единому конечному результату.

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

например. final_result зависит от предпоследнего

final_result: penultimate

предпоследний может быть выполнен любым из нескольких способов:

Если начинать с file1, то

penultimate: file1 ; rule1

Если начать с файла2, то

penultimate: file2 ; rule2

В: как мне указать, чтобы начать с файла2, а не с файла1?

Полагаю, я мог бы использовать переключатель командной строки и ifdeffing. Но я бы предпочел, чтобы make или scons выяснили: «Эй, вокруг есть файл2, поэтому я должен использовать rule2, а не fil1 / rule1». Частично потому, что сеть намного сложнее, чем эта ...

Хуже того, иногда промежуточное звено на одном пути может быть началом на другом. Давайте посмотрим:

A .s производит .diag

foo.diag: foo.s

Но иногда нет .s, и у меня просто есть .diag, который кто-то другой дал мне уже построенный.

.diag создает .heximg и .hwresult

foo.hwresult: hwsim foo.heximg

foo.heximg: foo.diag

Но иногда мне дают .img напрямую

1032 * Etc. *

Я просто хочу написать общий график зависимостей и сказать: «Хорошо, теперь вот что мне дали - теперь, как вы доберетесь до конечного результата?»

С тем, что у меня есть сейчас, когда мне дают, скажем, foo.img, мне говорят (в данном случае make) "foo.s not dfound". Потому что make хочет пройти весь путь назад в графе зависимостей, чтобы сказать, устарел ли foo.img, а я хочу сказать: «предположим, что foo.img обновлен, и работает для пересылок для вещей, которые зависят от foo.img». вместо того, чтобы возвращаться к вещам, от которых зависит foo.img. "

Ответы [ 2 ]

2 голосов
/ 26 февраля 2012

Вы должны делать все это с помощью шаблонных правил (неявных правил). Если вы укажете явное правило, то make считает, что это жесткая зависимость, и если какая-то часть зависимости не будет соблюдена, make потерпит неудачу.

Если вы используете неявное правило, то make сочтет, что ВОЗМОЖНЫЙ способ построить цель. Если этот способ не работает (потому что не существует каких-либо предварительных условий, а make не знает, как его построить), make попробует другой путь. Если никакой способ не работает, и цель уже существует, make просто использует эту цель, не обновляя ее.

Кроме того, вы говорите, что «.diag создает .heximg и .hwresult», затем приводите странный пример синтаксиса make-файла, который я не распознал, но для справки с шаблонными правилами вы можете указать, что одна команда создает несколько выходных не могу сделать это с явными правилами):

%.heximg %.hwresult: %.diag

Вот плохие новости: единственный способ определить неявное правило в make GNU - это если в имени файла есть общий «стержень». То есть вы можете написать неявное правило, которое преобразует foo.diag в foo.heximg, написав шаблонное правило «% .heximg:% .diag», потому что у них есть общая основа «foo», но нет способа создать шаблонное правило для компиляции от «foo1» до «предпоследнего», потому что они не имеют общего стебля.

1 голос
/ 27 февраля 2012

Я не уверен, но, вероятно, вы ищете Правила двоеточия :

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

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

...