Я думал, что больше всего на свете я ненавижу людей, которые включают -Werror в своем проекте. #werror

Но, вдруг, оказалось, что есть грех и посерьезнее, а именно, включить -Werror в configure скрипта своего проекта:

checking for boost/spirit/
    include/classic.hpp... no

Причина:

:216:64: error: declaration shadows 
    a field of 'subrule_parser<ID, DefT, 
    ContextT>' [-Werror,-Wshadow]
    operator,(subrule_parser<ID2, DefT2, 
    ContextT2> const& rhs) const

/mix/store/EXZAWbJZCAHZ5qTY-lib-boost/
    include/boost/spirit/home/classic/
    core/non_terminal/subrule.hpp:229:32:
    note: previous declaration is here

typename DefT::embed_t rhs;

———
https://mazzo.li/posts/fast-pipes.html

Интересный текст про передачу большого объема данных через пайпы.

Довольно интересно теоретически, но малополезно практически, потому что, когда вам надо будет передавать столько, вы все равно сделаете преаллоцированный буффер в пошаренной памяти, и будете передавать указатели на его страницы через pipe.

———
Интересное наблюдение - просмотрщики картинок редко когда зависят от imagemagick/graphicsmagic/freeimage/etc.

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

90% кода просмотрщика изображений - это фабрика, врапающая загрузку разных форматов в вектор rgb значений.

Моя теория заключается в том, что "так не интересно".

Люди любят OSS, потому что люди любят низковисящие фрукты(в прямом и переносном смысле), а в OSS легко заняться именно низковисящими фруктами.

В больших компаниях, в развитых кодовых базах их давно съели, и злой менеджер заставляет заниматься никому не нужным говном задачами, которые займут год и дадут полпроцента НЁХ.

А тут написал вечером загрузку png вдобавок к jpg - у тебя сразу программа в 2 раза лучше стала!

А если добавить поддержку IM, то поле для вкусных и недорогих улучшений сразу и пропадет.

Кстати, КМК, это одна из причин популярности новых языков типа Rust/Go. Они, конечно, лучше, чем старые, а еще там непаханое поле по разработке http сервера.

Это же круто - запилить сотую aio библиотеку, и получить 100500 звезд на гитхабе!

Я тут ничем не лучше, потому что вкусные фрукты вида "написал 5 строк кода, и у тебя в шедулере графа поддержка памяти и CPU ограничений" манят сильно.

https://jmmv.dev/2022/06/autoconf-caching.html

Интересный текст про одну малоизвестную фичу #autohell, и про ее полезное применение.

TL;DR - для configure можно заранее приготовить список ответов на вопросы про систему, которое оно задает.

В тексте указывается специальный ключ для configure скрипта, но, на практике, этим никто не пользуется.

Все просто выставляют переменные среды, которые читает configure скрипт:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdb/t/ix.sh#L33 - вот тут явыставляю, что у меня нет ada компилятора.

Все эти проверки написаны на shell, глючат от версии к версии, никто не полезет разбираться, почему эта конкретная проверка просто зависает, проверяя, что в clang нет поддержки Ada.

Все дистростроители про эту фичу знают, и активно ей пользуются. Почему? Потому что они работают, как говно, недавно писал про такой случай - #werror

Тут возникает резонный вопрос - а что, если посчитать все такие стандартные переменные, записать их в файлик для target platform, и применять перед каждым configure?

Мне, как proud owner своего дистрибутива, это:

* интересно

* довольно просто попробовать

Я однажды это и сделал, но почему-то не написал. Наверное, потому что это было еще до того, как я начал активно писать про #stal/IX, а потом просто забыл.

Статья мне про этот случай напомнила, вот, пишу.

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

Далее все довольно просто - объединяем их, берем часто встречающиеся, и образовывающие непротиворечивое подмножество. Да, иногда разные скрипты выставляют одну и ту же переменную в разные значения - это может означать, что эта переменная используется по разному, или глюк в autodetect.

В целом, профит хороший, скрипты ускоряются кто в 2 раза, кто на 20% - зависит от числа кастомных проверок и от их сложности.

Внедрил ли я это? Нет, пока не внедрил - страшно.

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

Ну и, на самом-то деле, профит не такой уж и большой, autohell в дистрибутивах все меньше и меньше.

Мне эта фича, скорее, интересна в плане кросс-компиляции, когда configure скрипты работают херово, по понятным причинам(криворукие авторы пытаются по запуску host программы что-то узнать про target систему).

#werror #rant

В копилку проектов, желающих мне смерти заебаться:

https://github.com/harfbuzz/harfbuzz/blob/main/src/hb.hh#L49-L97 - конечно, мы не только включим в meson Werror по умолчанию, так еще и досыпем всяких полезных (нет) предупреждений, которым сами не будем соответствовать!

Или вот - https://github.com/GNOME/pango/blob/main/meson.build#L91-L108

Коллеги, если вы ставите -Werror в свой проект, то вы обязуетесь убедиться, что оно работает корректно под всю матрицу поддерживаемых вами конпеляторов и OS.

Ладно, не обязуетесь, но если вы так не делаете - то вы больной на всю голову упырь зачем-то заставляете заебаться много людей на пустом месте!