Как работать с правилом сборки с неизвестными целями в OMake при создании генератора списка целей - PullRequest
Новая
       32

Как работать с правилом сборки с неизвестными целями в OMake при создании генератора списка целей

1 голос
/ 26 марта 2010

У меня есть проект, который использует OMake для своей системы сборки, и я пытаюсь справиться с довольно сложным угловым случаем.

У меня есть несколько файлов определений и инструмент, который может взять эти файлы определений и создать файлы GraphViz. Однако есть две проблемы:

  • Каждый файл определения может создавать несколько графиков, и список графиков, которые он может создать, кодируется в файле. У моего инструмента дампа есть опция -list, в которой перечислены все графики, которые будет генерировать файл определения.
  • Этот инструмент дампа встроен в дерево исходных текстов.
  • Я хочу, чтобы этот список был доступен в OMakefile, чтобы я мог использовать другие правила для преобразования файлов DOT в SVG и иметь фиктивную цель, зависящую от всех SVG (цель: одна команда построения, которая создает описания SVG для всех моих графиков) ).

Если бы у меня была только первая проблема, это было бы легко - я бы запустил инструмент для создания списка, а затем использовал этот список для создания цели, которая вызывает дампер для вывода файлов GraphViz. Тем не менее, я застрял на том, чтобы заставить инструмент дампа собираться до того, как он понадобится.

Если бы это было make, я бы просто рекурсивно запустил make, чтобы создать инструмент дампа. Однако OMake не допускает рекурсивный вызов, а функция build может использоваться только с osh.

.

Есть предложения для хорошего решения этой проблемы?

1 Ответ

1 голос
/ 14 апреля 2010

Хорошо, вот мое предложение. Во-первых, это быстрый генератор, созданный в bash, который может принимать аргумент «--list», который создает переменную omake, которая содержит список действий. Генератор называется «generator.txt», так как мы собираемся «сделать» его, переименовав в .sh. 

#!/bin/bash

if [ "$1" = "--list" ]; then
    echo -e 'FILES[] = \n\ta\n\tb\n\tc'
else
    echo 1 > a.dot
    echo 2 > b.dot
    echo 3 > c.dot
fi

Затем сам файл OMake: 

.INCLUDE: rules : generator.txt
    cp generator.txt generator.sh
    chmod 755 generator.sh  
    ./generator.sh
    ./generator.sh --list > rules

DOTS[] =
    $(addsuffix .dot, $(FILES))

SVGS[] =
    $(addsuffix .svg, $(FILES))

# rule to turn a .dot into a .svg
%.svg: %.dot
    cp $*.dot $*.svg

.DEFAULT: $(SVGS)

.PHONY: clean
clean:
    rm -f generator.sh a.* b.* c.* rules

Хитрость в том, чтобы сгенерировать файл «rules» из generator.txt, который будет включен в OMakefile. Всякий раз, когда generator.txt (исходный код нашего генератора) изменяется, мы воссоздаем (собираем) генератор, запускаем его (создаем файлы a.dot, b.dot, c.dot) и, наконец, запускаем его с --list для генерации нашего Переменная FILE [], содержащая список файлов для генерации.

Затем генерировать переменные DOTS и SVGS и правило, которое превращает точку в svg, становится тривиальным. Цель по умолчанию зависит от списка svgs, который будет собирать все по порядку.

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

Обратите внимание, как изменение generator.txt (например, добавление еще одного .dot для генерации или изменение способа создания содержимого .dot) корректно вызывает регенерацию generator.sh, а затем любого сгенерированного файла. который был бы изменен.

EDIT

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

Полагаю, есть способы обойти:

  • Во-первых, генератор должен быть скомпонован как часть директивы .INCLUDE, как я описал вначале, что создает трудности, поскольку вы должны поместить весь процесс сборки генератора в эту директиву.

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

  • Третий, который был бы моим любимым, - это двухфазная система сборки. В подкаталоге у вас есть OMakefile, который генерирует генератор и выводит файлы. В другом подкаталоге у вас есть другой OMakefile, который считывает содержимое первого каталога, чтобы сгенерировать список файлов для обработки, а затем выполняет преобразование. Затем в основном каталоге скрипт bash вызывает omake в первом каталоге, а затем во втором. Надеемся, это должно означать, что вы можете сгенерировать все с помощью одной команды, но также и то, что перестройка будет минимальной: первый omake будет регенерировать файлы только в случае изменения входных данных, а второй omake будет преобразовывать только измененные или новые файлы.

...