autoconf vs redo

Что: 17aa5a765f6ab4a81dc3e14bf8ecdcd5a88ac820

Когда: 2022-09-29 22:59:47+03:00

Темы: c redo

autoconf vs redo

Количество проектов на Си на работе плодится. И в них я использую redo
вместо Make и autoconf. Вообще конечно абсолютно некорректно сравнивать
redo и autoconf, ибо у них по сути не пересекающиеся задачи, но autoconf
это же ведь множество задач/целей, результат выполнения которых
используется, по сути, как зависимость для команд сборки. И кучу всяких
детектов как-раз можно описывать в виде redo целей. Но об этом уже писал
в 401c0f635a1cdfb01068a48a4cdf40791d3db458. Если в autoconf нужно знать
как этот сам framework, так ещё и основы M4, то в redo ничего не нужно
дополнительно: что хочешь, то и используй. Нужно Си программу
проверяющую работоспособность чего то? Делаешь цель, которая может
зависеть от уже имеющихся детектов флагов, компиляторов, других команд,
которая соберёт что нужно. Распараллеливание всех этих детектов из
коробки (ведь известно, что ./configure может выполняться существенно
дольше чем вообще вся сборка программы после него).

Сегодня понял про другой плюс: redo-log команда может показать вывод
связанный только и только с заданной целью. Если ./configure падает, то
это очень не тривиально найти место даже самого последнего падения в
config.log, ибо в конце там вывод далеко не последнего детекта.

Пока просматривал свою старую запись про замену autoconf, то удивился
что ещё проще у меня многое стало. Я полностью избавился от redo-stamp.
Я приводил пример с conf/cmd/cc.do целью, где основное содержание было:

    echo "${CC:-`command -v cc`}" > $3
    command -v redo-stamp > /dev/null || exit 0
    redo-stamp < $3

а теперь это conf/cmd/default.do:

    envname=`echo "$1" | tr a-z A-Z | tr - _`
    eval echo '${'$envname':-`command -v '$1'`}'

который применим к любой команде (это default цель), которую и через или
переменные окружения или config-файл в корне можно переопределить.

В моём прошлом примере было упоминание pkg-config-based цели. Но на
практике регулярно pkg-config нужен не только для определения одной
библиотеки и все эти цели идентичны и похожи, поэтому вместо
conf/flags/libcrypto.do:

    redo-ifchange ../../config ../cmd/pkg-config
    . ../../config
    read PKG_CONFIG < ../cmd/pkg-config
    cat < $src.c <
    int main(int argc, char **argv) { return 0; }
    EOF
    $CC -o /dev/null $src.c > /dev/null 2>&1 && printf "%s\n" "$GLIBC_CFLAGS" || echo

где факт компилирования с features.h вполне годится. А в других целях я
из этого файла возьму опциональные флаги нужные для ОС с glibc.
Аналогично я делаю Си программы которые уже что-то выводят (xxx.rc.do):

    redo-ifchange ../../config ../cmd/cc common.rc xxx.pc.rc
    read CC < ../cmd/cc
    . ./common.rc
    . ./xxx.pc.rc
    src=`mktemp`
    trap "rm -f $src $src.c" HUP PIPE INT QUIT TERM EXIT
    cat > $src.c <
    #include 
    int main(int argc, char **argv) {
        puts("{\\nread XXX_FOO_CTX_SIZE\\nread XXX_BAR_CTX_SIZE\\n} <

=> оставить комментарий

комментарий 0:

From: kmeaw
Date: 2022-10-01 16:17:18Z

> clean.do цель в директории может подчистить файлы

Если используется git, то можно сделать git clean -Xf - тогда будет
использоваться полноценный парсер .gitignore.

комментарий 1:

From: Sergey Matveev
Date: 2022-10-02 09:28:15Z

*** kmeaw [2022-10-01 19:16]:
>Если используется git, то можно сделать git clean -Xf - тогда будет
>использоваться полноценный парсер .gitignore.

Хм, не приходила эта мысль раньше. Выглядит здраво и красиво! И именно
сегодня как-раз появились в одном redo-driven проекте .gitignore-ы
которые действую на целой иерархии директорий, где просто sed/whatever
уже не подошёл бы. git clean как раз решает и эту проблему. Спасибо!

Сгенерирован: SGBlog 0.34.0

Proxy Information
Original URL
gemini://gemlog.stargrave.org/17aa5a765f6ab4a81dc3e14bf8ecdcd5a88ac820
Status Code
Success (20)
Meta
text/gemini
Capsule Response Time
145.49983 milliseconds
Gemini-to-HTML Time
0.637592 milliseconds

This content has been proxied by September (3851b).