#cross #cmake В CMake нет кросс-компиляции. Видимо, ее было сложно добавить постфактум(ну, не знаю, не глобальную переменную с набором environment завести, а сделать два экземпляра класса - для target, и для host). Вообще, добавить кросс-компиляцию в систему, которая для этого не дизайнилась изначально, сложно.

Ну и что же делать? Вот, вместо того, чтобы таки запилить кросс-компиляцию, товарищи запилили страничку, на которой, на голубом глазу, утверждают, что кросс-компиляция в CMake есть!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

Конечно есть! Только вам надо 1 раз прогнать cmake, собрать все провалившиеся вызовы TRY_RUN, записать их предполагаемые результаты в файлик, и прогнать это говно еще раз!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#using-compile-checks

Вдумчивый читатель спросит - а как в сборке запустить собранный host бинарь? А точно так же! Собираешь бинарь отдельно(твои проблемы, как), и подсовываешь его в cmake!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#running-executables-built-in-the-project

Так же несколько раз по тексту эти господа прозрачно намекают на wine, qemu, и прочие достижения прогресса, чтобы TRY_RUN таки работал.

Я подумал, что это какая-то outdated хрень, но вот, пжалста, инструкции по кросс-сборке #LLVM:

https://bcain-llvm.readthedocs.io/projects/llvm/en/latest/HowToCrossCompileLLVM

-DLLVM_TABLEGEN=<path-to-host-bin>/llvm-tblgen
-DCLANG_TABLEGEN=<path-to-host-bin>/clang-tblgen

Удобные переменные, чтобы передать путь к заранее предсобранным бинарничкам, чтобы CMake не перенапрягся. Вообще, удивительно, что у программы, которая облегчила кросс-компиляцию в 100500 раз, такая отстойная кросс-компилирующая сборка.

"Cross-compiling is fully supported by CMake, ranging from cross-compiling from Linux to Windows; cross-compiling for supercomputers, through to cross-compiling for small embedded devices without an operating system (OS)."

Феерические долбоебы.

———
Ну и вот вам еще душераздирающих историй. У меня тут свалилась сборка glslang, компилятора шейдеров от Khronos Group. Эти негодяи попросту поменяли файл по релизной ссылке:

Было:

https://github.com/KhronosGroup/glslang/
archive/refs/tags/master-tot.tar.gz
f51c4b12ac0c8f9dee2067dc207a4fca

Стало:

md5sum master-tot.tar.gz 
71c7f379d1d73eebdce3fd05c7727af4
master-tot.tar.gz

Не, по ссылке(и по предыдущему опыту взаимодействия) было понятно, что ссылка не жилец, но все же. Кстати, к тому, что по github commit id данные часто приезжают с другим md5, я уже давно привык, это какое-то общее место.

Собирал тут boost. Люди, которые меня хорошо знают, удивятся - я же известный boost hater. #gold

Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg

Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.

Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake

* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.

* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.

* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.

* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).

Теперь к B2/BJAM:

* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.

* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.

Вернусь к вчерашней ссылке про static vs. dynamic.

https://lobste.rs/s/adr60v/single_binary_executable_packages#c_xoxpbs

1) Там подняли интересные темы про статическую линковку в Rust и Go.

2) СЯУ, что в Rust нет кросс-компиляции. Ну, точнее, есть, по модели CMake(#cross #cmake на сайте написано, что есть, а cargo таки оперирует одним графом). Я это еще заприметил, когда только начал им пользоваться, но у меня не хватало уверенности, чтобы об этом сказать.

———
https://codeberg.org/dnkl/fuzzel/pulls/53

Автор #foot классный. Я как-то писал про проблему первого кадра в sway, так вот, коллега тоже обратил на нее внимание, и даже предложил решение.

———
https://rtpg.co/2022/02/13/your-own-sudo.html

Товарищи, если кто-то в вашей окружности решит написать sudo на python, пристрелите его.

* питон загружает много модулей
* авторам so-шек обычно нет выхода, кроме как заполучать параметры для себя через env
* man secure_getenv, и связанные с загрузкой so #suid-ными бинарями CVE.

———
https://gankra.github.io/blah/text-hates-you/
https://rastertragedy.com/RTRCh0.htm

Классные тексты про text rendering и text shaping.

Вообще, хочу сказать, что то, что эмодзи решили погрузить в шрифты - это, конечно, леденящий душу пиздец и layer violation, который до сих пор аукается. Почитайте, как разные люди решают задачу рендеринга эмодзи, это прекрасно.

Кстати, про шрифты - связка Inter + IBM Plex мне нравится даже больше, чем набор шрифтов в macOS.

Ненавижу #cmake.

Это самая худшая система сборки ever.

* Она не умеет в кросс-компиляцию, писал об этом неоднократно #cross

* Фактически, cmake - это интерпретируемый язык с смесью синтаксиса qbasic и cobol, на которой можно как-то написать кривую и косую систему сборки, потому что язык turing complete.

Сложность скриптов на cmake ограничивается только всратостью самого языка, и ничем более.

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

В cmake есть переменная, которая определяет список путей, по окторым искать библиотеки, заголовки, и так далее.

https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, вот она

Ее поведение можно переопределить 10 разными способами, например

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#variable:CMAKE_SYSTEM_PREFIX_PATH

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_IGNORE_PATH.html#variable:CMAKE_SYSTEM_IGNORE_PATH

find_package() в cmake содержит в себе 10 настроек для этих 10 переменных, https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package - искать по "NO_CMAKE_".

Каждая из которых каким-то нетривиально-всратым образом меняет семантику find_package.

Долбоебы из QT решили, что и этого им мало:

* они переопределили поведение по умолчанию, чтобы либы из QT не искались в CMAKE_PREFIX_PATH

* Они завели себе переменную QT_ADDITIONAL_PACKAGES_PREFIX_PATH, на замену CMAKE_PREFIX_PATH

* Они завели себе переменную, выключенную по умолчанию, которая возвращает поведение к "нормальному"(насколько это возможно в cmake вообще) - QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES

Я НЕНАВИЖУ, когда у программистов заканчивается работа, и они начинают маяться хуйтой.

———
Хозяйке на заметку.

Я потихоньку профилирую свой Linux, ищу, что и где плохо лежит происходит не так, как мне нравится, и починяю.

Вот, возможно, пригодится.

#foot по умолчанию запускает ncpu threads для параллельного рендеринга.

Но мы-то знаем, что дисперсия времен ответов от большого числа источников(иными словами, барьер на синхронизацию событий "мы все сделали!") штука опасная, и может быть большой. Например, потому что #scheduler в Linux - говно. Тем более, если запускать по 16 render threads. Ну и памяти под стеки они жрут прилично.

TL;DR - если убрать вообще все worker threads, и оставить только main, скорость рендеринга не меняется никак(проверяем с помощью cat на большой файл, с ansi escape codes)

Тащемта, понятно, откуда там взялся многопоток - автор foot, очевидно, испытывает комплекс перед #alacritty, и ему нужно были эти эфемерные 10% ради собственного спокойствия.

А вам я рекомендую ставить workers=0 в конфиге, работает так же, памяти жрет меньше.

https://www.opennet.ru/opennews/art.shtml?num=57847 #ball_lick

Тут вот пишут, что вышла новая версия #qt, и я хочу сказать, что сборка QT, после ее перехода на cmake - это леденящий душу пиздец.

Связано это с:

* #cmake сам по себе говно, в нем нет кросс-компиляции. А в QT есть, поэтому им пришлось написать соответствующий слой поверх cmake самим. #cross

* QT решили задачу по переходу, в том числе, оттранслировав большое число проектных файлов автоматом. Для этого им пришлось наговнякать большой runtime поверх макросов cmake, который имплементировал нужную им модель, в которую они и погрузили свои сборочные файлы. https://github.com/qt/qtwayland/blob/dev/src/qtwaylandscanner/CMakeLists.txt#L4

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

К чему этот rant?

https://github.com/pg83/ix/blob/main/pkgs/die/c/qt.sh#L16 - мне пришлось добавить пятый флажок в набор флажков, отвечающих за то, что нужно собрать тулзы, и, желательно, только их.

Реально, там полный набор - от "ну пожалуйста", до "мамой клянусь, они мне точно нужны".

А еще они зачем-то добавили факт о том, что пакет собран кросс-компиляцией, в метаинформацию этого пакета. https://github.com/pg83/ix/blob/main/pkgs/lib/qt/6/base/ix.sh#L45 (я ее вырезал, конечно)

Это вообще какая-то дичь, которую я для себя никак не могу объяснить:

* Их сборка начала ломаться, если этот флаг разный у разных пакетов. Схера ли? build tools могут быть собраны в режиме host == target, а либы - уже в режиме кросс-компиляции, это вполне валидный сценарий.

* А как же воспроизводимость? Пакет должен быть идентичный, неважно, в каком окружении он собран. А тут налицо факт, что пакеты, собранные кросс-компиляцией, будут отличаться.

Не могу не похвастаться. #cross

Я несколько раз упоминал, что одна из моих целей - это простая и дешевая кросс-компиляция, без мучительной настройки окружения.

С самого начала разработки #ix, я закладывал в него такую возможность - учет host/target в графе, возможность указывать библиотеки, нужные для сборки, в разных контекстах (host/target), прокидывание этой информации до cmake/meson/autohell, до каждого запуска clang/lld, и так далее.

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

Понятно же, что, когда тулчейн нужно собрать под host, а библиотеку этим тулчейном уже под host+LTO, это уже тоже кросс-компиляция?

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

И, вот, пожалуйста!

pg-> ./ix build lib/c++/15 --target=linux-aarch64 
READY /ix/store/eS3L7CZ3qS6dEkaX-rlm-ephemeral/touch
pg-> find /ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/Scrt1.o
/ix/store/...-rlm-ephemeral/lib/crti.o
/ix/store/...-rlm-ephemeral/lib/crtn.o
/ix/store/...-rlm-ephemeral/lib/crt1.o
/ix/store/...-rlm-ephemeral/lib/rcrt1.o
/ix/store/...-rlm-ephemeral/lib/libm.a
/ix/store/...-rlm-ephemeral/lib/librt.a
/ix/store/...-rlm-ephemeral/lib/libpthread.a
/ix/store/...-rlm-ephemeral/lib/libcrypt.a
/ix/store/...-rlm-ephemeral/lib/libutil.a
/ix/store/...-rlm-ephemeral/lib/libxnet.a
/ix/store/...-rlm-ephemeral/lib/libresolv.a
/ix/store/...-rlm-ephemeral/lib/libdl.a
/ix/store/...-rlm-ephemeral/lib/libcrt.a
/ix/store/...-rlm-ephemeral/lib/libc.a
/ix/store/...-rlm-ephemeral/lib/libc++abi.a
/ix/store/...-rlm-ephemeral/lib/libc++.a
/ix/store/...-rlm-ephemeral/lib/libc++unwind.a
pg-> llvm-objdump --disassemble 
    /ix/store/...-rlm-ephemeral/lib/crtn.o

crtn.o:  file format elf64-littleaarch64

Disassembly of section .init:

0000000000000000 <$x.0>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret

Disassembly of section .fini:

0000000000000000 <$x.1>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret
pg->

Понятно, что пока так собираются только самые базовые вещи, придется зачинивать кучу таргетов, которые, в процессе работы, строят и запускают host тулзы, но не умеют сами в кросс-компиляцию, но начало положено!

Забавно, что от "собрать пару либ" до "собрать содержательный пакет" - всего пара строк кода! #cross

pg-> ./ix build bin/sed --target=linux-aarch64
READY /ix/store/...-rlm-ephemeral/touch
pg-> /ix/store/...-bin-sed/bin/sed 
bash: /ix/store/...-bin-sed/bin/sed: 
    cannot execute binary file: 
    Exec format error
pg-> 

https://github.com/pg83/ix/commit/c9a76659a00c2b94974eb2c9edd67843cd85663a

Когда у тебя появляется микроскоп, то им обязательно хочется что-нибудь забить! #cross

Вот, у меня появилась новая игрушка - кросс-компиляция чего угодно откуда угодно, и я, например, решил проверить выводы про плотность кода.

pg-> ./ix build bin/xz --target=linux-aarch64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1897768 Jan 16 21:11

pg-> ./ix build bin/xz --target=linux-riscv64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1724848 Jan 16 21:14

pg-> ./ix build bin/xz --target=linux-x86_64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1787144 Jan 16 21:15

Мне системно делать это лень, но на примере 2 - 3 бинарников (я смотрел на sed, xz, и curl, в сниппете размеры для xz) я вижу другую закономерность - что у risc-v, наоборот, самый плотный код из всех!

Продолжаем тему кросс-компиляции. #cross #ix_run #dev_shell

Я теперь умею, например, так:

pg-> ./ix run \
    bin/qemu --for_target=aarch64-linux-user \
    bin/convert --target=linux-aarch64 \
    -- qemu-aarch64 '$(command -v convert)'

Что тут написано?

Тут написано: "собери мне realm, в котором есть host qemu, умеющий запускать arm бинарники, собери мне image magick convert под aarch64, и запусти в этом realm программу convert"

Что эта команда выводит на экран:

READY /ix/store/uFlUrE6DQMb3SC2l-rlm-ephemeral/touch
Version: ImageMagick 7.1.0-58 Q16-HDRI aarch64  
    https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI 
Delegates (built-in): bzlib fontconfig 
    freetype heic jng jp2 jpeg jxl lcms 
    openexr pangocairo png raw tiff 
    webp zlib
Compiler: gcc (4.2)
Usage: convert [options ...] 
    file [ [options ...] 
    file ...] [options ...] file

Обратите внимание, что запускается именно aarch64 бинарник convert!

Фактически, я умею в одном сборочном графе манипулировать артефактами, собранными под разные target platform.

Что нам это дает?

* https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh - дешевая автосборка и CI под другие платформы. Реально, добавить aarch64 в автосборку заняло 2 строчки в сборочных файлах. https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/linux/aarch64/ix.sh - список того, что я регулярно собираю под aarch64. Там есть и gdb, и даже графические программы!

* Новые возможности для #bootstrap. Например, go сейчас не является воспроизводимым с точки зрения классических способов (пакетных менеджеров и систем сборки), потому что последняя версия go, собираемая С-компилятором, не умеет строить код под M1, и не собирается под ним. Я теперь могу подступиться к этой проблеме, написав в сборочном файле для go что-то вроде:

{% block bld_tool %}
bin/qemu(for_target=linux-x86_64)
bin/kernel(target=linux-x86_64)
bin/busybox(target=linux-x86_64)
bin/go/1.4/(target=linux-x86_64)
{% endblock %}

Поднять в этом сборочном узле qemu (который сам себе и собрал), linux kernel, go1.4, и там провести цепочку #bootstrap. И это будет работать, в том числе, под host == darwin.

Мне сейчас кажется, что я достиг чего-то, чего ранее никто не делал в open source. Все автосборочные кросс-компилирующие решения, известные мне, основаны на том, что кто-то руками прикопал заранее собранные инструменты, поэтому они имеют довольно маленький scope.

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.

Будни #bootstrap, #cross

У меня уже довольно давно была поддержка кросс-компиляции с любого host на любой linux, и на всякие нишевые платформы типа #WASI

Вот, добавил darwin-{amr64,x86_64} - https://github.com/pg83/ix/commit/85c66407c092677519f45ee55b265bc272759ad5.

В коммите всякие мелочи, типа {% if linux %} на зависимости, которые не собираются под darwin, типа libsigsegv, libbsd, и так далее.

Так как у меня cross compile даже для host == target, ничего особо сложного в этом не было, все заработало из коробки.

Почему я не сделал это раньше?

Потому что все это время я думал, как половчее попиздить macos sdk!

Компания Apple, как и MS, не очень поощряет сборку не на своих OS/железе. У них это написано в лицензии.

Поэтому есть такой небезызвестный https://github.com/phracker/MacOSX-SDKs - смотреть можно, трогать пользоваться, кажется, нельзя.

При этом, я решал следующие задачи:

* Рандомный васян, скачав #IX, должен "из коробки" уметь собрать любую программулю под macos. Украдет он при этом что-то, или нет, - не мои проблемы.

* Если это запускается на родной платформе для macos, то, по умолчанию, надо брать установленные в систему SDK, и ничего не воровать.

* Если этот код запускается в каком-то частном контуре, то должна быть возможность указать на url, по которому будет лежать цельнопижженый легальный (с точки зрения владельца этого контура) слепок macos sdk. Например, он его купил, но за пределы контура распространять не может.

Соответственно, для васяна я качаю SDK с инторнетов, для host == target сборки даю возможность использовать родную SDK, ну а злые корпорации пусть в своем контуре используют то, что считают нужным, это не мое дело.

Все это я сделал моим любимым способом "dispatch по настройкам во все более специализированный таргет" - https://github.com/pg83/ix/blob/main/pkgs/lib/darwin/c/ix.sh#L3-L12

И сразу добавил нужные мне таргеты в мой CI - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh#L8-L9, это было совсем просто!

С windows sdk все будет, кажется, существенно хуже, потому что найти прямые ссылки на даже "серые" их версии у меня не получается. Везде всратый windows installer, который даже cabextract не берет. А выкладывать пижженый контент от своего имени мне бы не хотелось.

#cross, будни #bootstrap

Продолжаю тему кросс-компиляции в macos, https://t.iss.one/itpgchannel/1444

Прошла буквально неделя, а я уже умею собирать кросс-сборки довольно нетривиальных (использующих графику и прочие GUI) программ.

Вот, например, вам бинарник dosbox, статически слинкованный под macos-arm64, с linux-x86_64 host.

Без зависимостей от всяких всратых libSDL.dylib/libSDL2.dylib/etc.

(понятное дело, что он не полностью статически слинкован, это невозможно под macos, потому что там поверхность взаимодействия с системой - 100500 closed source фреймворков)

Мне интересно, будут ли с этим бинарником какие-то проблемы, связанные с таким необычным способом сборки, позапускайте (malware not included).

Будни #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-w64.org/ target.

#MinGW - это очень странная крича, которая одновременно решает следующие задачи:

* Околоавтоматически сгенерить заголовки для всех доступных виндовых API, в виде, понятному gcc/clang

* Долить в стандартную C библиотеку от винды (msvcrt, и да, я знаю про ucrt, но msvcrt есть под любую винду) какое-то количество unix-измов, которое можно добавить без расширения runtime самих Windows (короче, без fork(), но с pthreads)

У меня про эту задачу, на самом деле, есть два больших блока мыслей - один про технические проблемы, с которыми я столкнулся, и второй - про свое отношение к этой деятельности. Вот с него и начну!

Мое отношение к винде, с точки зрения ее поддержки в своем инструментарии, можно сформулировать так:

* С одной стороны, windows - довольно всратая самобытная платформа, не-Unix, во всем смыслах этого слова.
Поэтому поддержать ее как один из таргетов - интересная техническая задача, которую можно пытаться решить кучей разных способов, что доставляет само по себе. Ну вот вам, например, пара проектов, которые решают запуск MSVC тулчейнов через wine - https://github.com/yandex/yatool/blob/main/build/scripts/run_msvc_wine.py (моего изначального авторства, кстати, особенно доставляет, что туда добавлены ретраи, без этого никак), https://github.com/eruffaldi/wine_vcpp, https://github.com/mstorsjo/msvc-wine. Тысячи их.

* С другой - у меня есть сильное внутреннее нежелание это делать.

Почему?

Потому что Microsoft, в данном случае, негодяи и пидарасы!

Они специально сделали свои OS отличными от Unix там, где это вообще возможно, в рамках своей политики EEE. Очень классно - ты контролируешь значительную часть рынка, и делаешь свои API не совместимыми ни с чем, чтобы софт с твоей OS было запредельно дорого пртировать в другие OS. Это, кстати, довольно разумное бизнес решение так-то.

Но, зато, теперь, когда Windows утрачивает лидирующие позиции, я с удовольствием смотрю, как ей приходится заигрывать с Unix (тот же WSL), чтобы их OS, как среда разработки, продолжала бы иметь какой-то смысл. Без WSL, и без тулинга, который он предоставляет, разработка под винду - тихий ужас.

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

(Еще раз, повторю, что это было правильное в моменте решение, которое позволило MS стать теми, кто они есть, а не еще одним провайдером еще одного Unix, кстати, где они? Но любви и желания пилить что-то "под" это не добавляет).

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

Пилить поддержку винды как host платформы - да боже упаси, ни в жисть.

#cross

https://nixcademy.com/2024/01/30/cross-compilation-with-nix/

Годный текст про то, что кросс-компиляция - это сложно, но если сделать "правильно" (оценочное суждение), то будет просто.

Правильно - предлагается использовать мета-пакетную систему, типа nix/guix/ix.

К тексту могу добавить, что у меня кросс-компиляция сделана гораздо проще (для пользователя), и несколько сложнее внутри, поэтому у меня можно на любой конечный артефакт написать ix build bin/coreutils --target=darwin-arm64, и оно просто будет работать.

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

#cross

Сегодня я узнал, что help2man (от проекта #GNU) запускает только что скомпилированную программу, чтобы превратить ее --help в man file.

Не то чтобы это не было очевидно из названия этой тулзы, но, вот, в голову мне это не приходило.

И это, конечно, совершенно никак не ложится на кросс-компиляцию.

https://forums.gentoo.org/viewtopic-t-1141876.html

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

Этим, например, грешат всякие multicall бинари, чтобы получить список хендлеров, для того, чтобы построить симлинки с нужными именами.

Что я с этим сделал?

А нахуй послал.

Я как-то рассказывал, что у меня есть скрипт - "универсальная" замена любому codegen. Он анализирует свои аргументы, находит подходящий кандидат на output, и просто пишет в него 0 байт. (https://t.iss.one/itpgchannel/927, https://github.com/pg83/ix/blob/main/pkgs/bld/fake/er/ix.sh)

Ну я и заменил оригинальный help2man на затычку - https://github.com/pg83/ix/blob/main/pkgs/bld/help2man/ix.sh

#cross, будни #bootstrap

https://github.com/pg83/ix/compare/55e3c5e70b000885a39d3ae42f764626aca724de...pg83:ix:main

Вот, запилил поддержку armv7, в качестве target.

В ядре кода даже убавилось, потому что я радикально упростил обработку target, теперь это просто dict merge для набора словарей, получаемых отображением множества токенов из target, разделенных -. Ну, то есть, делим linux-armv7-gnueabihf на 3 токена, для каждого получаем множество его флагов, и объединяем их.

Как side effect, a-b-c, и b-c-a - это теперь могут быть разные таргеты, потому что при слиянии пар ключ - значение важен порядок. Пока не решил, хорошо это, или плохо.

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

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

Будни #bootstrap

https://t.iss.one/itpgchannel/1640
https://t.iss.one/itpgchannel/2210
https://t.iss.one/itpgchannel/471

Вот, кстати, вспомнилось, в продолжение этих трех (!) тем.

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

Недавно вышла новая версия makeinfo, от проекта GNU, и я решил, что не хочу пересобирать world еще и из-за этого, и, вместо makeinfo, начал подсовывать в сборки свою заглушку - https://github.com/pg83/ix/blob/main/pkgs/bld/texinfo/ix.sh

Тем более что документацию в формате texinfo пишут только сумасшедшие #GNU фанатики, ну и, как я уже однажды писал, она всегда доступна в веб, а если надо, то можно собрать нужный таргет и с настоящими makeinfo.

А кросс-компиляции как не было (https://t.iss.one/itpgchannel/132), так и нет. И не будет, ага.