Python Weekly
https://calpaterson.com/bank-python.html - например, про экосистему Питона в каком-то крупном банке(если не врут). Тепло, лампово, монорепозиторно.
https://github.com/ranger/ranger - трехпанельный навигатор на Python. К своему стыду, узнал о нем всего пару недель назад. В 5 раз больше звезд на гитхабе, чем у MC. Это переворачивает мое представление о вселенной.
https://www.trypyjion.com/ - за здравие:
"Profile Guided JIT Compiler
Native 64-bit float and integer support
Small, fast compiler
Windows, macOS and Linux
Intel and ARM CPU support
Builtin IL and ASM disassembler
Support for native debugging and profiling tools"
И сразу за упокой:
"Pyjion requires:
CPython 3.10
.NET 6"
https://tenthousandmeters.com/blog/python-behind-the-scenes-13-the-gil-and-its-effects-on-python-multithreading/
Годная статья про GIL в Python. Мне лично было интересно, как себя ведет питонячка со смешанной нагрузкой(io + CPU), никогда об этом раньше не задумывался. #gil
Ну и мое микроисследование про сборку python 3.10.
3.10 у меня собирается вот с такой ошибкой ./configure:
cat ./configure выглядит вот так:
А вот описание ошибки на SO: https://stackoverflow.com/questions/17089858/pkg-config-pkg-prog-pkg-config-command-not-found
"When that script calls autogen.sh, aclocal is failing to find pkg.m4, an M4 macro package that comes with pkg-config and provides the PKG_PROG_PKG_CONFIG macro. Where is pkg-config installed, and what directories is aclocal searching?"
#autohell
Что это значит? Это значит, что релиз инженер этой версии питона халатно подошел к своему делу, и не проверил результат. Это приводит к тому, что pkg-config не всегда используется для поиска пакетов в системе, иногда работают fallback на более старые механизмы. В целом, не очень серьезная проблема, просто иногда не работает autodetect чего-то в системе.
https://calpaterson.com/bank-python.html - например, про экосистему Питона в каком-то крупном банке(если не врут). Тепло, лампово, монорепозиторно.
https://github.com/ranger/ranger - трехпанельный навигатор на Python. К своему стыду, узнал о нем всего пару недель назад. В 5 раз больше звезд на гитхабе, чем у MC. Это переворачивает мое представление о вселенной.
https://www.trypyjion.com/ - за здравие:
"Profile Guided JIT Compiler
Native 64-bit float and integer support
Small, fast compiler
Windows, macOS and Linux
Intel and ARM CPU support
Builtin IL and ASM disassembler
Support for native debugging and profiling tools"
И сразу за упокой:
"Pyjion requires:
CPython 3.10
.NET 6"
https://tenthousandmeters.com/blog/python-behind-the-scenes-13-the-gil-and-its-effects-on-python-multithreading/
Годная статья про GIL в Python. Мне лично было интересно, как себя ведет питонячка со смешанной нагрузкой(io + CPU), никогда об этом раньше не задумывался. #gil
Ну и мое микроисследование про сборку python 3.10.
3.10 у меня собирается вот с такой ошибкой ./configure:
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for --with-libs... no
./configure: 10530: PKG_PROG_PKG_CONFIG: not found
cat ./configure выглядит вот так:
10525 { $as_echo "$as_me:
${as_lineno-$LINENO}: result: no" >&5
10526 $as_echo "no" >&6; }
10527 fi
10528
10529
10530 PKG_PROG_PKG_CONFIG
10531
10532 # Check for use of the system expat library
А вот описание ошибки на SO: https://stackoverflow.com/questions/17089858/pkg-config-pkg-prog-pkg-config-command-not-found
"When that script calls autogen.sh, aclocal is failing to find pkg.m4, an M4 macro package that comes with pkg-config and provides the PKG_PROG_PKG_CONFIG macro. Where is pkg-config installed, and what directories is aclocal searching?"
#autohell
Что это значит? Это значит, что релиз инженер этой версии питона халатно подошел к своему делу, и не проверил результат. Это приводит к тому, что pkg-config не всегда используется для поиска пакетов в системе, иногда работают fallback на более старые механизмы. В целом, не очень серьезная проблема, просто иногда не работает autodetect чего-то в системе.
calpaterson.com
An oral history of Bank Python
The strange world of Python, as used by big investment banks
Новости бутстрапа.
Я собрал opengl, во всех его ипостасях(egl, gles[1, 2, 3], etc). Про то, что у меня теперь драйвер видеокарты влинкован в Sway, я расскажу отдельно. А сегодня - про Mesa(https://www.mesa3d.org/). Mesa - это:
1) Реализация различных API(OpenGL, Vulkan, D3D(да, да, он там есть, нативный, но разработчики это скрывают, потому что не хотят, чтобы им пользовался кто-то, кроме Wine))
2) OSS ускоренные драйвера(AMD, Intel, Noveau, Mali, etc)
Вы знаете, я был очень приятно удивлен. Я никогда не видел такой хорошей кодовой базы на C. Чистый, понятный, код, разумное разделение на слои и разделение ответственности. Если вы хотите(хз, правда, зачем) научиться, как хорошо писать на С - почитайте кодовую базу Mesa.
Я почитал(зачем? проект загружает драйвера в виде .so, это требует некой творческой доработки для статической линковки), и имею вам сказать следующее:
1) Что-то я разуверился, что #asahi linux достигнет какого-то разумного прогресса в плане ускоренного десктопа. Все очень просто. Код для asahi в Mesa - это 200 килобайт, драйвер и компилятор шейдеров. Код развитого драйвера в #Mesa - 5 и более мегабайт. Я не верю в чудо, что разработчики asahi смогли уместить такую сложную штуку, как Apple GPU, в 200К. Я не видел там реализации по существу, все это больше похоже на какой-то boilerplate. :(
2) Благодаря Mesa появилась система сборки Meson(https://mesonbuild.com/). На ней основана сборка практически всего графического стека Linux. И это очень хорошая(не побоюсь сказать, что лучшая OSS) система сборки:
* Мало внешних зависимостей. Фактически, только Python. Python собрать проще и быстрее, чем CMake.
* Сборочные файлы основаны на кастрированном подмножестве Python, чтобы не жестить(https://mesonbuild.com/GuiTutorial.html). Skylark украл эту идею из Meson. Сборочные файлы по большей части декларативные, но немного императивщины дозволено - все же, OSS, много настроек, вариабельность.
* Действительно хорошая поддержка тулзов - Meson знает про clang, lld, и умеет с ними обращаться.
* Сборочные скрипты очень чистые и понятные - без жести, все очень по существу вопроса.
* Хорошо поддерживает вариабельность сборки(настройки). Настройки лежат в отдельном файле, их можно узнать, не читая сборочные скрипты. Это реально удобно. В gnu #autohell для этого нужно запустить configure, и не факт, что он выдаст все настройки. В CMake это IMHO вообще невозможно - любой -DXXX - это настройка, выгрепать их все - невозможно.
* Поддержка кросс-компиляции.
* Идеальный custom_command - {'inputs': [...], 'outputs': [...], 'descr': '...', cmd: ['A', 'B', 'C']}. Кто занимается системами сборки, тот поймет. Я аж прослезился.
* Не мешает, и даже помогает, задаче герметичной сборки. Это редкость.
* Очень быстрый configure stage.
* Не совсем про Meson, но. Оно поддерживает coverity из коробки. И werror из коробки. Это многое говорит о проектах, которые ее используют.
Подобное есть в Bazel, но он очень тяжелый, и зависит от Java.
В общем, я свои проекты портирую на #Meson, и вам желаю того же. Хорошая, годная, вещь.
Ну и вот еще - https://gms.tf/the-rise-of-meson.html Meson очень быстро набирает популярность!
Я собрал opengl, во всех его ипостасях(egl, gles[1, 2, 3], etc). Про то, что у меня теперь драйвер видеокарты влинкован в Sway, я расскажу отдельно. А сегодня - про Mesa(https://www.mesa3d.org/). Mesa - это:
1) Реализация различных API(OpenGL, Vulkan, D3D(да, да, он там есть, нативный, но разработчики это скрывают, потому что не хотят, чтобы им пользовался кто-то, кроме Wine))
2) OSS ускоренные драйвера(AMD, Intel, Noveau, Mali, etc)
Вы знаете, я был очень приятно удивлен. Я никогда не видел такой хорошей кодовой базы на C. Чистый, понятный, код, разумное разделение на слои и разделение ответственности. Если вы хотите(хз, правда, зачем) научиться, как хорошо писать на С - почитайте кодовую базу Mesa.
Я почитал(зачем? проект загружает драйвера в виде .so, это требует некой творческой доработки для статической линковки), и имею вам сказать следующее:
1) Что-то я разуверился, что #asahi linux достигнет какого-то разумного прогресса в плане ускоренного десктопа. Все очень просто. Код для asahi в Mesa - это 200 килобайт, драйвер и компилятор шейдеров. Код развитого драйвера в #Mesa - 5 и более мегабайт. Я не верю в чудо, что разработчики asahi смогли уместить такую сложную штуку, как Apple GPU, в 200К. Я не видел там реализации по существу, все это больше похоже на какой-то boilerplate. :(
2) Благодаря Mesa появилась система сборки Meson(https://mesonbuild.com/). На ней основана сборка практически всего графического стека Linux. И это очень хорошая(не побоюсь сказать, что лучшая OSS) система сборки:
* Мало внешних зависимостей. Фактически, только Python. Python собрать проще и быстрее, чем CMake.
* Сборочные файлы основаны на кастрированном подмножестве Python, чтобы не жестить(https://mesonbuild.com/GuiTutorial.html). Skylark украл эту идею из Meson. Сборочные файлы по большей части декларативные, но немного императивщины дозволено - все же, OSS, много настроек, вариабельность.
* Действительно хорошая поддержка тулзов - Meson знает про clang, lld, и умеет с ними обращаться.
* Сборочные скрипты очень чистые и понятные - без жести, все очень по существу вопроса.
* Хорошо поддерживает вариабельность сборки(настройки). Настройки лежат в отдельном файле, их можно узнать, не читая сборочные скрипты. Это реально удобно. В gnu #autohell для этого нужно запустить configure, и не факт, что он выдаст все настройки. В CMake это IMHO вообще невозможно - любой -DXXX - это настройка, выгрепать их все - невозможно.
* Поддержка кросс-компиляции.
* Идеальный custom_command - {'inputs': [...], 'outputs': [...], 'descr': '...', cmd: ['A', 'B', 'C']}. Кто занимается системами сборки, тот поймет. Я аж прослезился.
* Не мешает, и даже помогает, задаче герметичной сборки. Это редкость.
* Очень быстрый configure stage.
* Не совсем про Meson, но. Оно поддерживает coverity из коробки. И werror из коробки. Это многое говорит о проектах, которые ее используют.
Подобное есть в Bazel, но он очень тяжелый, и зависит от Java.
В общем, я свои проекты портирую на #Meson, и вам желаю того же. Хорошая, годная, вещь.
Ну и вот еще - https://gms.tf/the-rise-of-meson.html Meson очень быстро набирает популярность!
https://twitter.com/nicuveo/status/1469963644775682049
Красивое, просто показываю.
———
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=4
Не люблю perf тесты, которые делаю не сам. Вот zstd на FreeBSD - это что? Так же не бывает, что cpu intensive задача на разных OS в 10 раз отличалась.
———
https://github.com/NixOS/nixpkgs/issues/136926 - сломана кросс-сборка #Mesa.
https://habr.com/ru/post/591979/ - про основы кросс-компиляции в разных OSS системах сборки. Спойлер - Meson OK, #autohell и CMake - жесть.
Представление о 6 действиях, как собрать cross-gcc https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
Про CMake скажу отдельно - у него разных способов контролировать пути поиска тех или иных артефактов штук 10, разных, странных - поштырьте по ссылкам(https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#cmake-system-prefix-path).
Насколько я понимаю, для Mix это нормальное дело. Я строю Nix так, что он всегда кросс-компилирует, даже когда host == target. Это приводит к следующему:
1) Собрать программу полностью в debug/asan/msan/etc - плевое дело. Пользователи интерпрайзных систем сборки к этому привыкли, для OSS это внове.
2) Несколько необычный режим сборки промежуточных артефактов - каждый таргет может быть собран в 3 режимах - lib, bin, data. Нужно это потому, что разные артефакты нужны под host и target платформы, а еще библиотека может зависеть сама от себя, но от своих данных(это достаточно странно, но больше никак не сделать возможность удаления .a файлов, оставляя данные для них(кстати, вот как раз с динамической сборкой это проще - никого не удивляет, что .so живет рядом с share/)).
https://github.com/pg83/mix/blob/main/pkgs/lib/wayland/protocols/mix.sh - вот прекрасный пример, программа может зависеть от библиотеки lib/wayland, от бинарников из lib/wayland, и во время работы ей тоже нужны бинарники из lib/wayland. Если посчитать, то это 3 разных таргета в случае кросс-сборки. В случае host == target часть можно пооптимизировать, но я пока не занимался.
Красивое, просто показываю.
———
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=4
Не люблю perf тесты, которые делаю не сам. Вот zstd на FreeBSD - это что? Так же не бывает, что cpu intensive задача на разных OS в 10 раз отличалась.
———
https://github.com/NixOS/nixpkgs/issues/136926 - сломана кросс-сборка #Mesa.
https://habr.com/ru/post/591979/ - про основы кросс-компиляции в разных OSS системах сборки. Спойлер - Meson OK, #autohell и CMake - жесть.
Представление о 6 действиях, как собрать cross-gcc https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
Про CMake скажу отдельно - у него разных способов контролировать пути поиска тех или иных артефактов штук 10, разных, странных - поштырьте по ссылкам(https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#cmake-system-prefix-path).
Насколько я понимаю, для Mix это нормальное дело. Я строю Nix так, что он всегда кросс-компилирует, даже когда host == target. Это приводит к следующему:
1) Собрать программу полностью в debug/asan/msan/etc - плевое дело. Пользователи интерпрайзных систем сборки к этому привыкли, для OSS это внове.
2) Несколько необычный режим сборки промежуточных артефактов - каждый таргет может быть собран в 3 режимах - lib, bin, data. Нужно это потому, что разные артефакты нужны под host и target платформы, а еще библиотека может зависеть сама от себя, но от своих данных(это достаточно странно, но больше никак не сделать возможность удаления .a файлов, оставляя данные для них(кстати, вот как раз с динамической сборкой это проще - никого не удивляет, что .so живет рядом с share/)).
https://github.com/pg83/mix/blob/main/pkgs/lib/wayland/protocols/mix.sh - вот прекрасный пример, программа может зависеть от библиотеки lib/wayland, от бинарников из lib/wayland, и во время работы ей тоже нужны бинарники из lib/wayland. Если посчитать, то это 3 разных таргета в случае кросс-сборки. В случае host == target часть можно пооптимизировать, но я пока не занимался.
Twitter
Antoine Leblanc
"Two hosts are considered equivalent if both host names can be resolved into the same IP addresses[.] Since hosts comparison requires name resolution, this operation is a blocking operation." Oh no. OH NO. twitter.com/floydophone/st…
https://www.opennet.ru/opennews/art.shtml?num=56416
Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:
"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."
Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:
https://lists.busybox.net/pipermail/busybox/2006-September/058617.html
Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.
Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.
GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).
Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.
———
Busybox или Toybox?
Мне, конечно, ближе идея toybox(https://www.landley.net/toybox/faq.html#why_toybox).
Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.
Я верю в патчи и фидбек от OSS, а они достигаются широтой использования твоего кода. Даже если кто-то решит закрыть твой код, патчи ему будет выгоднее держать в upstream.
Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.
Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt
———
https://reviews.llvm.org/rG37e6bd8bc8da
К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.
———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025
Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:
"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."
Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:
https://lists.busybox.net/pipermail/busybox/2006-September/058617.html
Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.
Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.
GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).
Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.
———
Busybox или Toybox?
Мне, конечно, ближе идея toybox(https://www.landley.net/toybox/faq.html#why_toybox).
Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.
Я верю в патчи и фидбек от OSS, а они достигаются широтой использования твоего кода. Даже если кто-то решит закрыть твой код, патчи ему будет выгоднее держать в upstream.
Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.
Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt
———
https://reviews.llvm.org/rG37e6bd8bc8da
К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.
———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025
www.opennet.ru
Релиз минималистичного набора системных утилит BusyBox 1.35
Представлен релиз пакета BusyBox 1.35 с реализацией набора стандартных утилит UNIX, оформленных в виде единого исполняемого файла и оптимизированных для минимального потребления системных ресурсов при размере комплекта менее 1 Мб. Первый выпуск новой ветки…
👍1
https://ryanhileman.info/posts/lib43
https://gist.github.com/jboner/2841832
Специально поместил эти две ссылки рядом, чтобы желающие смогли на пальцах прикинуть, сколько времени должен исполняться типичный #autohell ./configure script. По моим прикидкам, если бы не sleep-ы в ядре Linux, секунд 5. А не 1 - 2 минуты, как сейчас.
———
https://www.mattkeeter.com/projects/synthesis/
Классный текст про использование SAT solver. Я в своей карьере использовал SAT solver 1 раз, для какой-то задачки с Эйлера, но знать про такую возможность, конечно, полезно.
———
https://www.opennet.ru/opennews/art.shtml?num=56422
Очень хорошая подборка материалов - что важного и интересного произошло в 21 году. Заметьте, что в тексте очень много ссылок, и почти все они ведут на новости с opennet.
Opennet - мой любимый новостной канал, там все появляется достаточно быстро, и новости хорошо пролинкованы между собой.
При этом, opennet, по современным меркам, очень странная площадка:
* Там есть Анонимус
* Все посылают друг друга нахуй
* Один из модераторов - фашист(не в смысле "плохой человек", а в смысле Википедии).
При этом:
* Там полное ощущение свободы и вольнодумия
* Даже этого модератора-фашиста все кроют хуями, а он в ответ не раздает банхаммер направо и налево(вот его лог модерирования - https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=list&forum=vsluhforumID3&open=moderator&n=Michael+Shigorin)(а на большом числе ресурсов модераторы не ссат показать такой лог?)
* Встречаются прямо очень интересные комментаторы.
И вот это слабо почищенное говно читать приятнее, чем эти ваши выхолощенные HN, и прочую левацкую поебень.
На самом деле, сравнивая opennet и HN, лично я прихожу к выводу, что свобода слова таки должна быть абсолютной, а желающие что-то запретить мне читать пускай настроят фильтр себе(а не мне).
Вот как предлагают бороться с троллингом на opennet - https://www.opennet.ru/tips/3195_ublock_filter.shtml
Это очень здоровая вещь, если подумать. Если что-то мешает лично тебе - то скрой это себе, и не пытайся скрыть для всех остальных.
https://gist.github.com/jboner/2841832
Специально поместил эти две ссылки рядом, чтобы желающие смогли на пальцах прикинуть, сколько времени должен исполняться типичный #autohell ./configure script. По моим прикидкам, если бы не sleep-ы в ядре Linux, секунд 5. А не 1 - 2 минуты, как сейчас.
———
https://www.mattkeeter.com/projects/synthesis/
Классный текст про использование SAT solver. Я в своей карьере использовал SAT solver 1 раз, для какой-то задачки с Эйлера, но знать про такую возможность, конечно, полезно.
———
https://www.opennet.ru/opennews/art.shtml?num=56422
Очень хорошая подборка материалов - что важного и интересного произошло в 21 году. Заметьте, что в тексте очень много ссылок, и почти все они ведут на новости с opennet.
Opennet - мой любимый новостной канал, там все появляется достаточно быстро, и новости хорошо пролинкованы между собой.
При этом, opennet, по современным меркам, очень странная площадка:
* Там есть Анонимус
* Все посылают друг друга нахуй
* Один из модераторов - фашист(не в смысле "плохой человек", а в смысле Википедии).
При этом:
* Там полное ощущение свободы и вольнодумия
* Даже этого модератора-фашиста все кроют хуями, а он в ответ не раздает банхаммер направо и налево(вот его лог модерирования - https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=list&forum=vsluhforumID3&open=moderator&n=Michael+Shigorin)(а на большом числе ресурсов модераторы не ссат показать такой лог?)
* Встречаются прямо очень интересные комментаторы.
И вот это слабо почищенное говно читать приятнее, чем эти ваши выхолощенные HN, и прочую левацкую поебень.
На самом деле, сравнивая opennet и HN, лично я прихожу к выводу, что свобода слова таки должна быть абсолютной, а желающие что-то запретить мне читать пускай настроят фильтр себе(а не мне).
Вот как предлагают бороться с троллингом на opennet - https://www.opennet.ru/tips/3195_ublock_filter.shtml
Это очень здоровая вещь, если подумать. Если что-то мешает лично тебе - то скрой это себе, и не пытайся скрыть для всех остальных.
Gist
Latency Numbers Every Programmer Should Know
Latency Numbers Every Programmer Should Know. GitHub Gist: instantly share code, notes, and snippets.
❤1
https://www.ttauri-project.org/2021/03/30/the-trouble-with-anti-aliasing.html
https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac
Два классных текста про рендеринг шрифтов. К счастью, разрешения наших экранов уже позволяют про все про это не думать - например, у меня на глаз не заметна разница между AA и не AA рендерингом уже.
———
https://www.gnu.org/software/libunistring/#downloading
У меня есть привычка - по вечерам обновлять версии софта, чтобы не залеживался. Вчера пришла очередь libunistring, это такая безумная библиотека от GNU, по обработке юникодных строк(вот, кстати, что про нее думают мои любимые suckless - https://libs.suckless.org/libgrapheme/).
Сборка библиотеки падала с cryptic сообщением, мол, не могу найти команду "@sed". Полез разбираться, оказывается, GNU сломали сборку своей же либы в своем же режиме в #autohell Makefile V=0, когда вместо команд печатаются их сокращения. С V=1 все отлично собралось.
———
https://lkml.org/lkml/2022/1/2/187
Я не пойму, в этом вашем ядре энтузиасты своего дела, кроме Ingo, остались? 3 коммента на классную инициативу по ускорению сборки за несколько дней.
Или все уже старые, сытые, и пьют пиво на праздниках?
———
https://habr.com/ru/news/t/599409/ #wot
Хорошо, конечно, что идут в суд, а не занимаются противоправной херней, как это стало модно.
Но, как бывший последовательный левый, потом неубедительно болтающийся у центра центрист, а теперь не менее последовательный правый, я, конечно, на стороне тех, кто выпускает хаки.
"Представитель Wargaming заявил, что компания считает создание и продажу программ, нарушающих правила игр и их внутреннюю экономику, таким же преступлением, как кража или мошенничество. "
Знаете, давайте уже сажать за высокочастотный трейдинг, или применение ML на фондовых рынках, а то как же так?
———
#server_push
https://www.opennet.ru/opennews/art.shtml?num=54069
Я, оказывается, проспал красивое. Если бы не проспал, то, конечно бы потребовал от всех, кто мне годами ел мозг чайной ложечкой насчет server push, немедленно извиниться за весь мой съеденный мозг.
https://medium.com/@evanwallace/easy-scalable-text-rendering-on-the-gpu-c3f4d782c5ac
Два классных текста про рендеринг шрифтов. К счастью, разрешения наших экранов уже позволяют про все про это не думать - например, у меня на глаз не заметна разница между AA и не AA рендерингом уже.
———
https://www.gnu.org/software/libunistring/#downloading
У меня есть привычка - по вечерам обновлять версии софта, чтобы не залеживался. Вчера пришла очередь libunistring, это такая безумная библиотека от GNU, по обработке юникодных строк(вот, кстати, что про нее думают мои любимые suckless - https://libs.suckless.org/libgrapheme/).
Сборка библиотеки падала с cryptic сообщением, мол, не могу найти команду "@sed". Полез разбираться, оказывается, GNU сломали сборку своей же либы в своем же режиме в #autohell Makefile V=0, когда вместо команд печатаются их сокращения. С V=1 все отлично собралось.
———
https://lkml.org/lkml/2022/1/2/187
Я не пойму, в этом вашем ядре энтузиасты своего дела, кроме Ingo, остались? 3 коммента на классную инициативу по ускорению сборки за несколько дней.
Или все уже старые, сытые, и пьют пиво на праздниках?
———
https://habr.com/ru/news/t/599409/ #wot
Хорошо, конечно, что идут в суд, а не занимаются противоправной херней, как это стало модно.
Но, как бывший последовательный левый, потом неубедительно болтающийся у центра центрист, а теперь не менее последовательный правый, я, конечно, на стороне тех, кто выпускает хаки.
"Представитель Wargaming заявил, что компания считает создание и продажу программ, нарушающих правила игр и их внутреннюю экономику, таким же преступлением, как кража или мошенничество. "
Знаете, давайте уже сажать за высокочастотный трейдинг, или применение ML на фондовых рынках, а то как же так?
———
#server_push
https://www.opennet.ru/opennews/art.shtml?num=54069
Я, оказывается, проспал красивое. Если бы не проспал, то, конечно бы потребовал от всех, кто мне годами ел мозг чайной ложечкой насчет server push, немедленно извиниться за весь мой съеденный мозг.
https://www.youtube.com/watch?time_continue=203&v=Zh3Yz3PiXZw&feature=emb_logo
Прекрасный видос, я, как обычно прослоупочил.
———
https://twitter.com/proffeynman/status/1038833676962869249?lang=en
Классный алгоритм, всегда им пользовался, теперь знаю, кто автор, и как называется.
———
Факир был пьян, фокус не удался.
yash отлично справляется с configure скриптами, но валится на каком-то bash-изме в libtool.
eval 'f ( X "" )' - что это? по мне так yash прав, что missing ), потому что f( - начало определения функции.
Видимо, автор dash это закостылял, потому что dash какое-то время был дефолтным shell в ubuntu(про сейчас не знаю). Без этого костыля #autohell проекты не собираются.
На закуску - автор yash упоролся, и переписывает его на Rust. https://github.com/magicant/yash-rs/issues
Вот зачем, зачем переписывать то, что уже написано и работает? Я там понимаю, если бы он фич хотел досыпать, но он же опять пишет posix shell.
———
https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/
range-based for-loop аккуратно обошли стороной. C++ doomed.
———
Intel отчаялась победить шедулер #sched в Linux, и теперь CPU просто сам говорит - "пошедули чего-нить на меня", или "я перегрет" https://www.tomshardware.com/news/intel-alder-lake-thread-director-support-coming-to-linux
А чо, норм тема, производитель процов явно же лучше знает, как нагрузить его поделие полезной работой.
Прекрасный видос, я, как обычно прослоупочил.
———
https://twitter.com/proffeynman/status/1038833676962869249?lang=en
Классный алгоритм, всегда им пользовался, теперь знаю, кто автор, и как называется.
———
Факир был пьян, фокус не удался.
yash отлично справляется с configure скриптами, но валится на каком-то bash-изме в libtool.
eval 'f ( X "" )' - что это? по мне так yash прав, что missing ), потому что f( - начало определения функции.
Видимо, автор dash это закостылял, потому что dash какое-то время был дефолтным shell в ubuntu(про сейчас не знаю). Без этого костыля #autohell проекты не собираются.
На закуску - автор yash упоролся, и переписывает его на Rust. https://github.com/magicant/yash-rs/issues
Вот зачем, зачем переписывать то, что уже написано и работает? Я там понимаю, если бы он фич хотел досыпать, но он же опять пишет posix shell.
———
https://botondballo.wordpress.com/2022/01/03/2021-c-standardization-highlights/
range-based for-loop аккуратно обошли стороной. C++ doomed.
———
Intel отчаялась победить шедулер #sched в Linux, и теперь CPU просто сам говорит - "пошедули чего-нить на меня", или "я перегрет" https://www.tomshardware.com/news/intel-alder-lake-thread-director-support-coming-to-linux
А чо, норм тема, производитель процов явно же лучше знает, как нагрузить его поделие полезной работой.
YouTube
Alternative Math | Short Film
A well meaning math teacher finds herself trumped by a post-fact America.
Хотел бы я написать, что переезд под полное управление моим пакетным менеджером заработало like a charm, но увы.
* у меня нет /lib, /usr, и прочей лабуды. При попытке скомпилировать gcc(для того, чтобы собрать ведро, clang я тут пока не доверяю), gcc на голубом глазу мне заявил, что у меня в системе не хватает папки /usr/include, и он не может запустить свой процесс fixincludes.
Вот хороший текст про это от автора musl, почитайте. https://ewontfix.com/12/
Вот фикс от arch - https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L57
Мне такой не подошел, потому что у меня ломается раньше, так как папки /usr нет вообще. Зато я нашел configure опцию! https://github.com/pg83/mix/blob/main/pkgs/bin/gcc/11/mix.sh#L50
Кстати, давно хотел рассказать про такой fun fact про configure. #autohell позволяет в одном дереве исходников разместить несколько проектов с ./configure скриптами. Тогда верхнеуровневый configure будет проксировать все неизвестные опции вниз, и узнать, какие опции есть, решительно невозможно.
Так вот, fun fact - у проектов gcc, gdb, binutils - общий(ну, почти одинаковый, немного разъезжается) верхнеуровневый configure, c опциями от gcc. Это, конечно, добавляет понимания, как эти проекты собирать.
* В процессе персборки мира я столкнулся со странными падениями сборки, когда один проект не мог найти другой. Потратил на поиски этой проблемы несколько часов, пока не понял, что:
1) Все случаи - когда cmake проект не может найти meson проект.
2) Во всех случаях установка meson проекта была несколько странной - вместо ${out}/include/blah.h было ${out}/include/${ver}/blah.h
Это должно было нивелироваться *.pc файлами, которые разруливают пути.
Тут до меня дошло, что я забыл к cmake проектам дописать зависимость от pkg-config, и ранее использовался системный. После этого все прошло like a charm, герметичная сборка рулит.
Я мог бы все контейнеризовать, но не хочу, потому что под mac это сложно, а я хочу и для него обеспечивать герметичность.
* у меня нет /lib, /usr, и прочей лабуды. При попытке скомпилировать gcc(для того, чтобы собрать ведро, clang я тут пока не доверяю), gcc на голубом глазу мне заявил, что у меня в системе не хватает папки /usr/include, и он не может запустить свой процесс fixincludes.
Вот хороший текст про это от автора musl, почитайте. https://ewontfix.com/12/
Вот фикс от arch - https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L57
Мне такой не подошел, потому что у меня ломается раньше, так как папки /usr нет вообще. Зато я нашел configure опцию! https://github.com/pg83/mix/blob/main/pkgs/bin/gcc/11/mix.sh#L50
Кстати, давно хотел рассказать про такой fun fact про configure. #autohell позволяет в одном дереве исходников разместить несколько проектов с ./configure скриптами. Тогда верхнеуровневый configure будет проксировать все неизвестные опции вниз, и узнать, какие опции есть, решительно невозможно.
Так вот, fun fact - у проектов gcc, gdb, binutils - общий(ну, почти одинаковый, немного разъезжается) верхнеуровневый configure, c опциями от gcc. Это, конечно, добавляет понимания, как эти проекты собирать.
* В процессе персборки мира я столкнулся со странными падениями сборки, когда один проект не мог найти другой. Потратил на поиски этой проблемы несколько часов, пока не понял, что:
1) Все случаи - когда cmake проект не может найти meson проект.
2) Во всех случаях установка meson проекта была несколько странной - вместо ${out}/include/blah.h было ${out}/include/${ver}/blah.h
Это должно было нивелироваться *.pc файлами, которые разруливают пути.
Тут до меня дошло, что я забыл к cmake проектам дописать зависимость от pkg-config, и ранее использовался системный. После этого все прошло like a charm, герметичная сборка рулит.
Я мог бы все контейнеризовать, но не хочу, потому что под mac это сложно, а я хочу и для него обеспечивать герметичность.
GitHub
svntogit-packages/trunk/PKGBUILD at packages/gcc · archlinux/svntogit-packages
Automatic import of svn 'packages' repo (read-only mirror) - archlinux/svntogit-packages
👍8
Q: Антон, почему тебе так не нравится Rust? #школота
A: Мне Rust очень нравится, у меня даже в планах написать на нем пару программ для Mix, не очень сложных, как раз для того, чтобы въехать:
* process supervisor, для выставления nice, ionice, приоритетов, rt scheduler, блокировок, subreaper, управления логами, и так далее. Сейчас это все сделано разными тулзами, поэтому в системе неоптимальное число процессов(subreaper отдельно, flock отдельно).
* graph executor, для пакетного менеджера. Сейчас это питонячка, не очень красиво.
Мешает мне только то, что Rust не работает в статическом окружении, и я раз в пару недель трачу вечер выходного дня, чтобы это как-то починить:
* mrustc. К сожалению, ничего, кроме Rust он собрать не может.
* docker образ с компилятором и glibc. На крайний вариант, сложно, пока не делал.
* запилить сборку glibc + patchelf на бинари с Rust.
Меня в Rust бесит:
* community. Школота и фанбои. Настолько бесит, что лезть туда не хочется.
* Хайп вокруг. Знаете, каждый язык, наверное, должен пройти статию "гля, еба, мы написали ядро на X". С это прошел когда, в 72-73 году? С++ в 80-ых? Читать об этом интересно, находиться в моменте - как получается, не очень.
Хайп бесит потому, что мешает отделять зерна от плевел. Каждую новость про Rust или очереднуюперемогу перписывание чего-то на Rust надо пропускать через сито, как вот с шедулером PopOS.
———
Больше всего на свете я люблю, когда пакет содержит в себе 2 или больше систем сборок.
Казалось бы, авторы подумали вообще обо всем, даже об этом?
Какое там:
* А чем собирается проект в своей CI? Какая из систем сборок наиболее поддерживаема?
* Часто результат не совпадает! Бывает, что cmake сборка не ставит .pc файлы, а #autohell/Makefile ставят. Или вот сегодняшний пример, от чего меня и взбугуртнуло-то - nlohmann-json при сборке через meson не ставит ${out}/lib/cmake/* файлы, и потом cmake проекты не могут его автоматически подхватить.
Короче, не делайте несколько систем сборок, сделайте одну, нормально, и поддерживаемо.
Отдельно, конечно, хочется сказать большое человеческое "спасибо"(нет) авторам cmake, за изобретение lib/cmake/*.cmake для автоконфигурации, это на порядок хуже простых .pc файлов, и ломается на каждый чих.
A: Мне Rust очень нравится, у меня даже в планах написать на нем пару программ для Mix, не очень сложных, как раз для того, чтобы въехать:
* process supervisor, для выставления nice, ionice, приоритетов, rt scheduler, блокировок, subreaper, управления логами, и так далее. Сейчас это все сделано разными тулзами, поэтому в системе неоптимальное число процессов(subreaper отдельно, flock отдельно).
* graph executor, для пакетного менеджера. Сейчас это питонячка, не очень красиво.
Мешает мне только то, что Rust не работает в статическом окружении, и я раз в пару недель трачу вечер выходного дня, чтобы это как-то починить:
* mrustc. К сожалению, ничего, кроме Rust он собрать не может.
* docker образ с компилятором и glibc. На крайний вариант, сложно, пока не делал.
* запилить сборку glibc + patchelf на бинари с Rust.
Меня в Rust бесит:
* community. Школота и фанбои. Настолько бесит, что лезть туда не хочется.
* Хайп вокруг. Знаете, каждый язык, наверное, должен пройти статию "гля, еба, мы написали ядро на X". С это прошел когда, в 72-73 году? С++ в 80-ых? Читать об этом интересно, находиться в моменте - как получается, не очень.
Хайп бесит потому, что мешает отделять зерна от плевел. Каждую новость про Rust или очередную
———
Больше всего на свете я люблю, когда пакет содержит в себе 2 или больше систем сборок.
Казалось бы, авторы подумали вообще обо всем, даже об этом?
Какое там:
* А чем собирается проект в своей CI? Какая из систем сборок наиболее поддерживаема?
* Часто результат не совпадает! Бывает, что cmake сборка не ставит .pc файлы, а #autohell/Makefile ставят. Или вот сегодняшний пример, от чего меня и взбугуртнуло-то - nlohmann-json при сборке через meson не ставит ${out}/lib/cmake/* файлы, и потом cmake проекты не могут его автоматически подхватить.
Короче, не делайте несколько систем сборок, сделайте одну, нормально, и поддерживаемо.
Отдельно, конечно, хочется сказать большое человеческое "спасибо"(нет) авторам cmake, за изобретение lib/cmake/*.cmake для автоконфигурации, это на порядок хуже простых .pc файлов, и ломается на каждый чих.
🔥9👍4👎2🤔1
Мне тут в комментариях посоветовали вместо gnome files собрать https://wiki.lxde.org/ru/PCManFM #pcmanfm
Мне это показалось хорошим вариантом, часть LXDE, ни от чего не зависит(ну, почти), на вид выглядит не очень страшно.
Что характерно, поддержку gtk3 в нем запилило сообщество Arch, а, значит, проект пользуется некоторой популярностью, потому что так-то сообщество - жопа ленивая обычно.
Замечания по ходу процесса:
* libfm для сборки потребовало gtk-doc, причем практически неотключаемым образом.
Про свои муки с #docbook я уже как-то писал, но тут получилось, что просто так обойти эту зависимость не получается.
Небольшое лирическое отступление. Проекты на GNU #autohell требуют для построения configure наличие dev части некоторых зависимых пакетов, даже если ты потом не захочешь использовать этот пакет, и отключишь его через —disable-XXX.
Поэтому зависимость от gtk-doc я пока решил так - у меня корректно собирается и устанавливается часть gtk-doc, нужная для генерации autohell скриптов, а вот потом, если не позвать —disable-gtk-doc в configure, все будет взрываться самым неприятным образом. Я, конечно, нужный —disable- зову.
* libfm потребовала некую libmenu-cache, которая потребовала libfm. Я тут немного прифигел, но таки да:
https://github.com/lxde/menu-cache
"Since version 0.7.0 the Libmenu-cache requires Libfm-extra for the menu-cache-gen menu cache generation binary. Since Libfm depends on Libmenu-cache, there is some hint for bootstrapers how to build those libraries together: you need create Libfm-extra first, you can easily do this by passing '--with-extra-only' option to configure script and installing Libfm-extra."
С моей точки зрения:
* коллега нагадил посреди комнаты
* вместо того, чтобы тихонько прибраться, повесил табличку "я нагадил, обход тут"
"А что подумал по этому поводу Кролик, никто так и не узнал, потому что Кролик был очень воспитанный"
(нет, Кролик был в ахуе, и выпал в осадок так-то)
* К сожалению, посреди процесса сборки уже самого pcmanfm, я обнаружил, что оно таки непосредственно зависит от X11, и я не могу это собрать и использовать.
Сначала я решил, что ну и хер с ним, но потом внимательнее посмотрел на код, и понял, что могу изящно обойти эту зависимость от X, потому что она используется только если запустить этот FM в качестве X Desktop.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/pcmanfm/mix.sh#L34
По сути, мне пришлось заменить один файлик размером 200К на несколько заглушек. Попрошу отметить, как я изящно расставил abort() в некоторых местах, чтобы быть уверенным, что мы не обсчитываем мусор. Все очень надежно!
Короче, оно даже запустилось, и даже заработало, с некоторыми глюками. Не работает прокрутка мышью, я это списываю на то, что никто и никогда этот код с Wayland не запускал, по понятным причинам. На вид чистенько, бедненько, все, как я люблю в софте.
Самое неприятное, конечно, в другом: #libmagic
Я успел прочитать часть кода, связанную с mime info, и с запуском приложений. Код рыхлый, неприятный, видно, что проект затащили грубой силой. Знаете, вот возникает момент, когда надо выделить функцию, а ты все равно в 10 местах вставляешь еще 1 if.
Поэтому за час у меня не получилось переделать всю эту машинерию на запуск xdg-open вместо своей таблицы отображения mime types на команду, а без этого у меня оно пока неюзабельно.
Пока отложил в сторону.
Мне это показалось хорошим вариантом, часть LXDE, ни от чего не зависит(ну, почти), на вид выглядит не очень страшно.
Что характерно, поддержку gtk3 в нем запилило сообщество Arch, а, значит, проект пользуется некоторой популярностью, потому что так-то сообщество - жопа ленивая обычно.
Замечания по ходу процесса:
* libfm для сборки потребовало gtk-doc, причем практически неотключаемым образом.
Про свои муки с #docbook я уже как-то писал, но тут получилось, что просто так обойти эту зависимость не получается.
Небольшое лирическое отступление. Проекты на GNU #autohell требуют для построения configure наличие dev части некоторых зависимых пакетов, даже если ты потом не захочешь использовать этот пакет, и отключишь его через —disable-XXX.
Поэтому зависимость от gtk-doc я пока решил так - у меня корректно собирается и устанавливается часть gtk-doc, нужная для генерации autohell скриптов, а вот потом, если не позвать —disable-gtk-doc в configure, все будет взрываться самым неприятным образом. Я, конечно, нужный —disable- зову.
* libfm потребовала некую libmenu-cache, которая потребовала libfm. Я тут немного прифигел, но таки да:
https://github.com/lxde/menu-cache
"Since version 0.7.0 the Libmenu-cache requires Libfm-extra for the menu-cache-gen menu cache generation binary. Since Libfm depends on Libmenu-cache, there is some hint for bootstrapers how to build those libraries together: you need create Libfm-extra first, you can easily do this by passing '--with-extra-only' option to configure script and installing Libfm-extra."
С моей точки зрения:
* коллега нагадил посреди комнаты
* вместо того, чтобы тихонько прибраться, повесил табличку "я нагадил, обход тут"
"А что подумал по этому поводу Кролик, никто так и не узнал, потому что Кролик был очень воспитанный"
(нет, Кролик был в ахуе, и выпал в осадок так-то)
* К сожалению, посреди процесса сборки уже самого pcmanfm, я обнаружил, что оно таки непосредственно зависит от X11, и я не могу это собрать и использовать.
Сначала я решил, что ну и хер с ним, но потом внимательнее посмотрел на код, и понял, что могу изящно обойти эту зависимость от X, потому что она используется только если запустить этот FM в качестве X Desktop.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/pcmanfm/mix.sh#L34
По сути, мне пришлось заменить один файлик размером 200К на несколько заглушек. Попрошу отметить, как я изящно расставил abort() в некоторых местах, чтобы быть уверенным, что мы не обсчитываем мусор. Все очень надежно!
Короче, оно даже запустилось, и даже заработало, с некоторыми глюками. Не работает прокрутка мышью, я это списываю на то, что никто и никогда этот код с Wayland не запускал, по понятным причинам. На вид чистенько, бедненько, все, как я люблю в софте.
Самое неприятное, конечно, в другом: #libmagic
Я успел прочитать часть кода, связанную с mime info, и с запуском приложений. Код рыхлый, неприятный, видно, что проект затащили грубой силой. Знаете, вот возникает момент, когда надо выделить функцию, а ты все равно в 10 местах вставляешь еще 1 if.
Поэтому за час у меня не получилось переделать всю эту машинерию на запуск xdg-open вместо своей таблицы отображения mime types на команду, а без этого у меня оно пока неюзабельно.
Пока отложил в сторону.
🔥8👍1
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 систему).
Интересный текст про одну малоизвестную фичу #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 систему).
Julio Merino (jmmv.dev)
Speeding up autoconf with caching - Julio Merino (jmmv.dev)
In the recent Remembering Buildtool post, I described how setting up a cache of configuration checks was an important step in Buildtool’s installation process. The goal was to avoid pointless …
🔥4👍1
Я пару раз писал про то, что совершенно не доверяю тестам от #phoronix.
Еще я писал про то, как люблю проекты, в которых поддержано 3 разных системы сборки, и непонятно, какую из них выбрать.
И, буквально вчера, про сложность отлабки проблем с configure скриптами(в общем, не только от #autohell).
Вот, пожалуйте, как в воду глядел - https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Bizarre-Zstd
TL;DR - Михаил тестировал разные дистрибутивы Linux на perf, и у него оказалось, что zstd сильно медленнее в Arch, чем в остальных дистрибутивах.
Выяснилось:
* Что arch использует cmake сборку(я тоже), остальные - простой Makefile
* В cmake сборке используется не тот стандарт на C, что и в остальных сборках. В Makefile - default, в cmake, вроде, с99, в meson - gnu99(есть и такой, они там совсем кукухой поехали).
* Бага только в многопоточном тесте, бага в использовании тормозного таймера - https://github.com/facebook/zstd/pull/3165/commits/376b9a0be4cc2972f2d2c4074ae1b6dfbe381330
https://github.com/facebook/zstd/issues/3163#issuecomment-1159627324
Что я могу сказать?
* Сборка OSS программ - это очень subtle вещь. Поэтому я, например, так и не перешел на более быстрый shell для запуска configure, и использую всратые coreutils.
* Phoronix заинтересованы в сенсации, а не в корректном и скучном освещении событий. Поэтому, когда там где-то написано, что freebsd выигрывает у linux в 2 раза, или наоборот - то это не заслуга OS, блин, не могут OS реально настолько отличаться, особенно в CPU intensive, а степень кривизны рук авторов configure(которые могут включить ассемблерные вставки только под Linux, например), или Миши, которому насрать.
(Побугурчу про Мишу, его стиль письма очень доставляет. Найдете хоть один текст без слова "exciting" - киньте мне, помещу под стекло. Степень его экзальтированности зашкаливает)
Я ничо делать не стал, потому что, напомню, я плевал на особое мнение upstream, и у меня есть clang wrapper, который определяет оптимизации так, как я считаю правильным.
Ну и проблема только в тесте, а Makefile у них кривой донельзя, не зря я(и Arch) выбрал cmake.
Еще я писал про то, как люблю проекты, в которых поддержано 3 разных системы сборки, и непонятно, какую из них выбрать.
И, буквально вчера, про сложность отлабки проблем с configure скриптами(в общем, не только от #autohell).
Вот, пожалуйте, как в воду глядел - https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Bizarre-Zstd
TL;DR - Михаил тестировал разные дистрибутивы Linux на perf, и у него оказалось, что zstd сильно медленнее в Arch, чем в остальных дистрибутивах.
Выяснилось:
* Что arch использует cmake сборку(я тоже), остальные - простой Makefile
* В cmake сборке используется не тот стандарт на C, что и в остальных сборках. В Makefile - default, в cmake, вроде, с99, в meson - gnu99(есть и такой, они там совсем кукухой поехали).
* Бага только в многопоточном тесте, бага в использовании тормозного таймера - https://github.com/facebook/zstd/pull/3165/commits/376b9a0be4cc2972f2d2c4074ae1b6dfbe381330
https://github.com/facebook/zstd/issues/3163#issuecomment-1159627324
Что я могу сказать?
* Сборка OSS программ - это очень subtle вещь. Поэтому я, например, так и не перешел на более быстрый shell для запуска configure, и использую всратые coreutils.
* Phoronix заинтересованы в сенсации, а не в корректном и скучном освещении событий. Поэтому, когда там где-то написано, что freebsd выигрывает у linux в 2 раза, или наоборот - то это не заслуга OS, блин, не могут OS реально настолько отличаться, особенно в CPU intensive, а степень кривизны рук авторов configure(которые могут включить ассемблерные вставки только под Linux, например), или Миши, которому насрать.
(Побугурчу про Мишу, его стиль письма очень доставляет. Найдете хоть один текст без слова "exciting" - киньте мне, помещу под стекло. Степень его экзальтированности зашкаливает)
Я ничо делать не стал, потому что, напомню, я плевал на особое мнение upstream, и у меня есть clang wrapper, который определяет оптимизации так, как я считаю правильным.
Ну и проблема только в тесте, а Makefile у них кривой донельзя, не зря я(и Arch) выбрал cmake.
Phoronix
The Bizarre Case Of Zstd's Very Slow Performance On Arch Linux
Yesterday I posted benchmarks of six Linux distributions on the HP Dev One, the exciting new Linux laptop launched by HP in collaboration with System76 that is using their Pop!_OS distribution
👍6👎1
Я тут, при очередной пересборки мира, обнаружил в dmesg красивое:
Это, конечно, очень грустно, потому что:
* если это происходит на этапе configure, то gnu #autohell кладет с прибором на это знание, и просто считает, что в системе нет какой-то фичи.
* если такое произошло во время сборки - то это особенно плохо, потому что, получается, где-то есть makefile, игнорирующий ошибки. А это, как вы сами понимаете, просто леденящий душу пиздец, потому что бывает segfault, а бывает что на сборочной ферме место закончилось.
Я заново пересобрал мир, без кеша, грепнул лог, и нашел, что так себя ведет сборка graphviz:
https://github.com/pg83/ix/blob/main/pkgs/bin/graphviz/autohell/ix.sh#L69
Такое ощущение, что там race с генерацией .c/.h файлов из grammar.y (грамматика на bison), и компилятор получает на вход неполный файл.
Ощущение такое, потому что сборка в один поток помогла.
В graphviz есть две системы сборки, одна на autohell, вторая - на cmake.
Сначала я попробовал переделать все на cmake сборку, но там напрочь сломана возможность статической линковки, потому что, в рамках одной программы, получается 2 определения функции:
https://gitlab.com/graphviz/graphviz/-/blob/main/lib/pack/ccomps.c#L671
https://gitlab.com/graphviz/graphviz/-/blob/main/lib/gvpr/actions.c#L110
Функции разные, сигнатуры - разные, имя одно.
Треш, угар, содомия, я решил попробовать полечить сборку с autohell, и набрел на решение со сборкой в один поток.
Наверное, по результатам импровизированного субботнего LSR, надо бы с этим сделать что-то системное, например, следить за ошибками в dmesg во время выполнения графа сборки.
[316266.607298] clang[19065]: segfault at 0
ip 00000000070e1d80 sp 00007efe96c97808
error 4 in clang-15[3613000+3ad7000]
[316266.607306] Code: 09 80 38 ...
Это, конечно, очень грустно, потому что:
* если это происходит на этапе configure, то gnu #autohell кладет с прибором на это знание, и просто считает, что в системе нет какой-то фичи.
* если такое произошло во время сборки - то это особенно плохо, потому что, получается, где-то есть makefile, игнорирующий ошибки. А это, как вы сами понимаете, просто леденящий душу пиздец, потому что бывает segfault, а бывает что на сборочной ферме место закончилось.
Я заново пересобрал мир, без кеша, грепнул лог, и нашел, что так себя ведет сборка graphviz:
https://github.com/pg83/ix/blob/main/pkgs/bin/graphviz/autohell/ix.sh#L69
Такое ощущение, что там race с генерацией .c/.h файлов из grammar.y (грамматика на bison), и компилятор получает на вход неполный файл.
Ощущение такое, потому что сборка в один поток помогла.
В graphviz есть две системы сборки, одна на autohell, вторая - на cmake.
Сначала я попробовал переделать все на cmake сборку, но там напрочь сломана возможность статической линковки, потому что, в рамках одной программы, получается 2 определения функции:
https://gitlab.com/graphviz/graphviz/-/blob/main/lib/pack/ccomps.c#L671
https://gitlab.com/graphviz/graphviz/-/blob/main/lib/gvpr/actions.c#L110
Функции разные, сигнатуры - разные, имя одно.
Треш, угар, содомия, я решил попробовать полечить сборку с autohell, и набрел на решение со сборкой в один поток.
Наверное, по результатам импровизированного субботнего LSR, надо бы с этим сделать что-то системное, например, следить за ошибками в dmesg во время выполнения графа сборки.
🤔9😐7👍1🤯1
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D0%BD%D1%83%D1%81%D0%B0
Вот есть 3 популярные в open source системы сборки - cmake, meson, #autohell.
И во всех трех есть определенные проблемы с #cross-компиляцией:
* В #cmake ее просто нет. Много раз писал и буду писать, что она у него совершенно фейковая, для отчета горе-программистов, которые ее делали, перед начальством.
* GNU #autohell содержит зачатки кросс-компиляции (умеет искать host compiler, например), но дальше ты сам по себе - фактически, нужно руками писать все сборочные правила для host сборок, без всякой на то помощи. Искать host библиотеки через pkg-config? Боже упаси, это же просто космос!
* meson наиболее продвинут в этом отношении, но и в нем есть свои проблемы. Например, очень странный способ указывать host/target тулзы, через материализованный файл, с не очень понятным синтаксисом.
При этом, ни одна из этих систем не является cross-native (#cross_native)!
(я сам изобрел этот термин, не ищите)
Что это значит?
Это значит, что кросс-компиляция туда добавлена постфактум, и не является родной. То есть, по умолчанию, предполагается, что ты можешь запустить любую свежесобранную тулзу, а чтобы было "не так", разработчики конкретной сборки должны знать, что бывает кросс-компиляция, и специально для этого присесть (повторю, meson в этом помогает, autohell не мешает, cmake мешает активно).
При чем тут закон Линуса?
А при том, что, несмотря на это, меньше всего проблем с кросс-компиляцией мне доставляют проекты на #autohell, просто потому, что они старые, потому, что их успело облизать огромное число человек, и кому-то уже было НАДА запилить в этих проектах кросс-компиляцию.
Как я предлагаю поступать с кросс-компиляцией в open source?
Я советую:
* Или писать весь код, который надо запустить на host системе, на интерпретируемом языке, типа python.
* Или разбивать свои проекты на библиотеки и программы в разные проекты на github (или в разные папочки одного проекта, но с возможностью собрать по отдельности все составляющие части), и сопрягать их мета-сборкой, типа nix/ix/guix.
Вот есть 3 популярные в open source системы сборки - cmake, meson, #autohell.
И во всех трех есть определенные проблемы с #cross-компиляцией:
* В #cmake ее просто нет. Много раз писал и буду писать, что она у него совершенно фейковая, для отчета горе-программистов, которые ее делали, перед начальством.
* GNU #autohell содержит зачатки кросс-компиляции (умеет искать host compiler, например), но дальше ты сам по себе - фактически, нужно руками писать все сборочные правила для host сборок, без всякой на то помощи. Искать host библиотеки через pkg-config? Боже упаси, это же просто космос!
* meson наиболее продвинут в этом отношении, но и в нем есть свои проблемы. Например, очень странный способ указывать host/target тулзы, через материализованный файл, с не очень понятным синтаксисом.
При этом, ни одна из этих систем не является cross-native (#cross_native)!
(я сам изобрел этот термин, не ищите)
Что это значит?
Это значит, что кросс-компиляция туда добавлена постфактум, и не является родной. То есть, по умолчанию, предполагается, что ты можешь запустить любую свежесобранную тулзу, а чтобы было "не так", разработчики конкретной сборки должны знать, что бывает кросс-компиляция, и специально для этого присесть (повторю, meson в этом помогает, autohell не мешает, cmake мешает активно).
При чем тут закон Линуса?
А при том, что, несмотря на это, меньше всего проблем с кросс-компиляцией мне доставляют проекты на #autohell, просто потому, что они старые, потому, что их успело облизать огромное число человек, и кому-то уже было НАДА запилить в этих проектах кросс-компиляцию.
Как я предлагаю поступать с кросс-компиляцией в open source?
Я советую:
* Или писать весь код, который надо запустить на host системе, на интерпретируемом языке, типа python.
* Или разбивать свои проекты на библиотеки и программы в разные проекты на github (или в разные папочки одного проекта, но с возможностью собрать по отдельности все составляющие части), и сопрягать их мета-сборкой, типа nix/ix/guix.
Wikipedia
Закон Линуса
Зако́н Ли́нуса (англ. Linus's Law) — любое из двух известных эмпирических наблюдений.
🔥4🤔4👍2👌1🆒1
Все же, нет сборочной системы хуже, чем gnu #autohell.
(давние читатели, наверное, заметили, что я держу две системы сборки в "самых худших" - cmake, и gnu autohell, а вот кто из них хуже - это уже дело ситуативное)
У нее есть такой хитрый режим сборки, когда в одну папку можно положить несколько отдельных проектов на autohell, написать один общий configure, и оно будет как-то пытаться все это собрать.
Прямо очень условное устройство таких проектов:
Иногда мне нужно декомпозировать сборку таких проектов, например, в случае gettext - чтобы отдельно собирать инструментарий gettext, и отдельно - libintl.
Так как такая схема сборки косая и кривая, разработчикам, которые ее используют, приходится жестить:
* разработчики gettext/tools захотели напрямую заиспользовать исходничек из соседнего проекта - https://github.com/autotools-mirror/gettext/blob/master/gettext-tools/src/Makefile.am#L295. Ну и просто добавили его в свой Makefile!
Казалось бы, что может пойти не так?
Все шло совершенно так, пока кто-то не захотел в этот вот localealias.c добавить include на генерируемый в процессе сборки файл (вот исходник для файла - https://github.com/autotools-mirror/gettext/blob/master/gettext-runtime/intl/libgnuintl.in.h,как он по цепочке попадает в localealias.c - неважно)
Понятное дело, что теперь сборка всего проекта получила race, и теперь он не может быть собран параллельно, нужно в определенном порядке позвать configure и make в этой общей структуре проектов, чтобы эти неучтенные зависимости были готовы, когда реально нужны.
Можно ли это как-то починить (если считать, что эта зависимость там реально нужна)? Без перехода на более хорошую систему сборки, или глубокого рефакторинга сборочных файлов старой - сомневаюсь.
Я это починил так:
* https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L34 - занулил плохой файл
* добавил зависимость от libintl (где есть нужный объектный код) в сборку gettext/tools - https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L11
Мораль? Как обычно, ее нет.
(давние читатели, наверное, заметили, что я держу две системы сборки в "самых худших" - cmake, и gnu autohell, а вот кто из них хуже - это уже дело ситуативное)
У нее есть такой хитрый режим сборки, когда в одну папку можно положить несколько отдельных проектов на autohell, написать один общий configure, и оно будет как-то пытаться все это собрать.
Прямо очень условное устройство таких проектов:
# cat configureТак собираются gcc, gdb, и, вот, gettext - https://github.com/autotools-mirror/gettext.
...
sh A/configure
sh B/configure
sh libC/configure
...
Иногда мне нужно декомпозировать сборку таких проектов, например, в случае gettext - чтобы отдельно собирать инструментарий gettext, и отдельно - libintl.
Так как такая схема сборки косая и кривая, разработчикам, которые ее используют, приходится жестить:
* разработчики gettext/tools захотели напрямую заиспользовать исходничек из соседнего проекта - https://github.com/autotools-mirror/gettext/blob/master/gettext-tools/src/Makefile.am#L295. Ну и просто добавили его в свой Makefile!
Казалось бы, что может пойти не так?
Все шло совершенно так, пока кто-то не захотел в этот вот localealias.c добавить include на генерируемый в процессе сборки файл (вот исходник для файла - https://github.com/autotools-mirror/gettext/blob/master/gettext-runtime/intl/libgnuintl.in.h,как он по цепочке попадает в localealias.c - неважно)
Понятное дело, что теперь сборка всего проекта получила race, и теперь он не может быть собран параллельно, нужно в определенном порядке позвать configure и make в этой общей структуре проектов, чтобы эти неучтенные зависимости были готовы, когда реально нужны.
Можно ли это как-то починить (если считать, что эта зависимость там реально нужна)? Без перехода на более хорошую систему сборки, или глубокого рефакторинга сборочных файлов старой - сомневаюсь.
Я это починил так:
* https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L34 - занулил плохой файл
* добавил зависимость от libintl (где есть нужный объектный код) в сборку gettext/tools - https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L11
Мораль? Как обычно, ее нет.
GitHub
GitHub - autotools-mirror/gettext: GNU gettext. Mirror of git://git.savannah.gnu.org/gettext.git
GNU gettext. Mirror of git://git.savannah.gnu.org/gettext.git - GitHub - autotools-mirror/gettext: GNU gettext. Mirror of git://git.savannah.gnu.org/gettext.git
👍7😱7🐳4🖕2😁1
commit -m "better"
Будни #bootstrap, #cross, #rant Вот, запилил какую-то поддержку Windows, для cross сборок. И сразу добавил в свой CI - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/mingw/w64/ix.sh С помощью родных sdk пока не стал делать, запилил в https://www.mingw…
Продолжаю рассказ про #MinGW #windows
Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #GNU #autohell позволяет настроить расширение для собранной статической библиотеки.
Настройка эта доступна не тому, кто запускает готовый
Поэтому я не могу пойти и параметризировать свои обвязки этим расширением, потому что его надо настраивать per project, а потом переделывать кучу моих скриптов, которые везде (до этого времени), полагали, что работают с
Я сделал несколько подходов к снаряду:
* Попробовал руками запатчить все проекты, чтобы свести все к
* Попробовал указать в качестве libtool стороннюю реализацию - https://github.com/midipix-project/slibtool Это работало удивительно хорошо, кроме тех случаев, когда не работало вовсе. Ну, например, у libtool есть режим "перелинковки" программ при их установке (наверное, для систем, в которых нет rpath). Зачем этот режим иногда срабатывал в случае статлинковки - неизвестно. Как отключить - неизвестно. А сторонняя реализация (совершенно справедливо!) это говно мамонта не поддерживает.
* В конце-концов, пришел к следующему - указал в качестве libtool один каноничный libtool на все проекты, который сам и подготовил заранее. Тут тоже есть свои косяки, потому что, наверняка, в этот каноничный libtool намешано знаний не только про target, но и про host, ну да хрен с ним. Пока этот вариант требует наименьшего вмешательства в сборочные скрипты.
Комбинация 2) и 3) позволила вообще не патчить исходные сборочные скрипты, и обойтись настройкой того, какой libtool использовать в проекте.
Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #GNU #autohell позволяет настроить расширение для собранной статической библиотеки.
Настройка эта доступна не тому, кто запускает готовый
configure, а запрятана где-то глубоко в настройках libtool/libtoolize (не спрашивайте, всратые гнутые скрипты, призванные облегчить линковку динамических библиотек под разные платформы). И, что самое удивительное, мейнтейнеры этой настройкой активно пользовались - у кого-то это lib, а у кого-то - a.Поэтому я не могу пойти и параметризировать свои обвязки этим расширением, потому что его надо настраивать per project, а потом переделывать кучу моих скриптов, которые везде (до этого времени), полагали, что работают с
.a файлами.Я сделал несколько подходов к снаряду:
* Попробовал руками запатчить все проекты, чтобы свести все к
.a файлам. Быстро задолбался и прекратил.* Попробовал указать в качестве libtool стороннюю реализацию - https://github.com/midipix-project/slibtool Это работало удивительно хорошо, кроме тех случаев, когда не работало вовсе. Ну, например, у libtool есть режим "перелинковки" программ при их установке (наверное, для систем, в которых нет rpath). Зачем этот режим иногда срабатывал в случае статлинковки - неизвестно. Как отключить - неизвестно. А сторонняя реализация (совершенно справедливо!) это говно мамонта не поддерживает.
* В конце-концов, пришел к следующему - указал в качестве libtool один каноничный libtool на все проекты, который сам и подготовил заранее. Тут тоже есть свои косяки, потому что, наверняка, в этот каноничный libtool намешано знаний не только про target, но и про host, ну да хрен с ним. Пока этот вариант требует наименьшего вмешательства в сборочные скрипты.
Комбинация 2) и 3) позволила вообще не патчить исходные сборочные скрипты, и обойтись настройкой того, какой libtool использовать в проекте.
GitHub
GitHub - midipix-project/slibtool: a surrogate libtool implementation, written in C
a surrogate libtool implementation, written in C. Contribute to midipix-project/slibtool development by creating an account on GitHub.
🤯6👍5🔥4❤3👎1🤔1
https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html
#autohell
Годный текст про autoconf, от коллегиблоггера мейнтейнера void linux.
С чем-то я согласен, можно сколько угодно ругать autohell, но он был первым в своем классе, было бы странно ожидать, что там все было сделано правильно с первого раза:
* "Overrides are possible". В cmake они тоже есть, но не стандартизированы, и работают не всегда ожидаемым образом. В meson это, вообще говоря, боль, потому что там ничего заоверрайдить нельзя, или я не нашел, как, поэтому если попадается какой-то всратый configure test, приходится патчить сборочные файлы.
* "The config.log tells what happened" В meson/cmake лог конфигурирования - это тихий ужас, чаще всего по нему невозможно понять, что же пошло не так.
С чем-то не согласен:
* "There is support for cross-compiling and for host/target separation". Как я уже когда-то писал, в autohell/cmake нет нормальной поддержки кросс-компиляции. #cross В meson немного лучше, там есть отдельные графы для host/target сборок, и можно проверять host свойства системы отдельно. Autohell, в лучшем случае, не мешает кросс-компиляции, cmake - просто вредит ей https://t.iss.one/itpgchannel/132.
* "It has few runtime dependencies" - это просто полуправда. Для запуска configure достаточно shell, но для его регенерации нужен m4/perl, а это уже очень и очень много. С точки зрения supply chain attack configure скрипты, конечно, надо всегда перегенерировать, как показал опыт проекта #xz_gate https://t.iss.one/itpgchannel/1789.
https://lobste.rs/s/ebnqzl/what_autoconf_got_right
#autohell
Годный текст про autoconf, от коллеги
С чем-то я согласен, можно сколько угодно ругать autohell, но он был первым в своем классе, было бы странно ожидать, что там все было сделано правильно с первого раза:
* "Overrides are possible". В cmake они тоже есть, но не стандартизированы, и работают не всегда ожидаемым образом. В meson это, вообще говоря, боль, потому что там ничего заоверрайдить нельзя, или я не нашел, как, поэтому если попадается какой-то всратый configure test, приходится патчить сборочные файлы.
* "The config.log tells what happened" В meson/cmake лог конфигурирования - это тихий ужас, чаще всего по нему невозможно понять, что же пошло не так.
С чем-то не согласен:
* "There is support for cross-compiling and for host/target separation". Как я уже когда-то писал, в autohell/cmake нет нормальной поддержки кросс-компиляции. #cross В meson немного лучше, там есть отдельные графы для host/target сборок, и можно проверять host свойства системы отдельно. Autohell, в лучшем случае, не мешает кросс-компиляции, cmake - просто вредит ей https://t.iss.one/itpgchannel/132.
* "It has few runtime dependencies" - это просто полуправда. Для запуска configure достаточно shell, но для его регенерации нужен m4/perl, а это уже очень и очень много. С точки зрения supply chain attack configure скрипты, конечно, надо всегда перегенерировать, как показал опыт проекта #xz_gate https://t.iss.one/itpgchannel/1789.
https://lobste.rs/s/ebnqzl/what_autoconf_got_right
👍11
https://t.iss.one/tech_b0lt_Genona/5344
Тут вот коллега пишет, как устроен autoconf скрипт в Python.
Я и про #autohell писал, в товарных количествах (для затравки - а вы знаете, что configure может пропустить сегфолт в своих conftest?), и про баги #autohell в Python - https://t.iss.one/itpgchannel/88
Могу сказать, что автор прошелся слегка по верхам, потому что у меня с этим configure "было всякое".
Вот, например, как через configure отключить сборку произвольного модуля Python?
Тут вот коллега пишет, как устроен autoconf скрипт в Python.
Я и про #autohell писал, в товарных количествах (для затравки - а вы знаете, что configure может пропустить сегфолт в своих conftest?), и про баги #autohell в Python - https://t.iss.one/itpgchannel/88
Могу сказать, что автор прошелся слегка по верхам, потому что у меня с этим configure "было всякое".
Вот, например, как через configure отключить сборку произвольного модуля Python?
🔥10❤🔥5🤡3🆒2👏1