Будни #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 платформы - да боже упаси, ни в жисть.

Продолжаю рассказ про #MinGW #windows

Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #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 использовать в проекте.

Продолжаю рассказ про странности платформы #MinGW.

На этот раз про сборку под нее через #cmake.

Я очень (ну, реально, ОЧЕНЬ, минут 15) долго искал, как этот target называется в cmake. Указать что-то человекопонятное, типа MinGW, MinGW32, MinGW64, приводило к тому, что cmake жаловался на то, что не знает такой платформы. Вот примерно с такими ошибками - https://discourse.cmake.org/t/system-is-unknown-to-cmake-create-platform-mingw64-nt-10-0-19044/4734

В инторнетах полно разного рода советов, как компилировать под mingw - предлагается использовать target MSYS/MSYS2. Но это не совсем то же самое - это не только mingw, но и еще какой-то тулинг вокруг, и все ломалось самым всратым образом.

Кто-то раздает феерические советы типа "а заведите себе сами такую платформу" - https://discourse.cmake.org/t/system-is-unknown-to-cmake-create-platform-mingw64-nt-10-0-19044/4734

Кто-то реально создает такие дескрипторы платформы для cmake - https://gist.github.com/peterspackman/8cf73f7f12ba270aa8192d6911972fe8

Вот из одного такого я и понял всю мякотку, всю глубинную суть - https://gist.github.com/peterspackman/8cf73f7f12ba270aa8192d6911972fe8#file-mingw-w64-x86_64-cmake-L9

mingw, с точки зрения cmake, это "Windows".

О как! Если указать такую target platform, то все начинает более-менее компилироваться, как надо.

В целом, это даже немного оправдано, потому что набор заголовочных файлов и библиотек ну очень уж похож.

За исключением одной мааааленькой, но важной, проблемы - довольно много сборочных скриптов полагает, что "Windows" == "MSVC" (довольно спорное, хотя и понятное, предположение), и начинает хреначить под эту платформу флаги компиляции "как для msvc" - https://github.com/lloyd/yajl/blob/master/CMakeLists.txt#L46

Короче, сборка под mingw под cmake доставляет, и без пердолинга патчинга некоторых сборочных файлов там не обойтись.