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

Хорошо, вот мое предложение. Во-первых, вот быстрый генератор, сделанный в 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

Затем сам OMakefile:

.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

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

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

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

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

РЕДАКТИРОВАТЬ

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

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

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

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

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