Git 2.48

Практика последних лет и куча дерьмовых скриптов в папках cmake крупных проектов показывает, что разработчикам для сборочной системы нужен нормальный script-like язык, а не обрубыш-DSL вроде CMake на котором скриптовать сценарии сборки сплошная боль.

Ты же противоречишь очевидным фактам. Для 99% проектов и разработчиков нужен компактный, но простой в использовании, освоении и поддержке DSL, а скриптовые расширения нужны в 1% случаев.

Сборочные системы на скриптах… Ну да писались и пишутся. На шелле, на перле, на питоне. Но DSL это уровень выше.

а скриптовые расширения нужны в 1% случаев.

Но когда они понадобятся, то вместо того чтобы говнокодить CMake <=> Python мосты, можно просто взять и задействовать их.

Для 99% проектов и разработчиков нужен компактный, но простой в использовании, освоении и поддержке DSL

И CMake здесь явно предлагает не лучший пример такого DSL. Он явно некомпактный (if/endif), непростой (постоянно нужно лазить в доки и гуглить), нелогичный (постоянно нужно ловить mindfuck’и от ожидаемых логичных конструкций), а его поддержка выливается в сущий ад.

Нормальный скриптовый язык вместо CMake-ссанины помогли бы вот этот откровенно-костыльный кал убрать из CMake-скриптов:

https://github.com/libsdl-org/SDL/blob/4294c0683611bc6cca4e0c5c7fe44e69a841dc0b/CMakeLists.txt#L1292-L1303

Где вместо очевидного cflags.replace('-mthumb', '-marm') нагородили какой-то чуши, переложив ответственность на компилятор:

Так как CMake убог и заменить в нём один флаг на другой – боль, мы просто насрём во флаги -marm -mthumb в надежде что у компилятора детерминирован выбор ARM и заглушение Thumb при наличие этих двух флагов.

P.S. Сборочная система Android NDK (ndk-build) это умела в лёгкую.

Тут регрессия при переходе ndk-build => CMake случилась, которую разрабы SDL забили таким уродливым костылём.

Так и что ты имеешь против Python’а и любого другого нормального скриптового языка в качестве сборочной системы?

Много ты, кстати, знаешь скриптовых языков переживших хотя бы 20ти-летний рубеж? Тот же питон в нынешнем виде версии 3 существует всего лишь с 2008 года. Напомнить каков был переход 2->3? А если бы мы начали раньше? Перл стал популярным и стандартом в каждом дистрибутиве задолго до питона. Чуть раньше он показался бы отличным выбором. А что ты скажешь сегодня про сборочную систему на перловке? А что там было популярно до того, лисп, шелл?

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

Если уж брать какой-то скриптовый язык, то он должен быть во-первых сначала стандартизован. Во-вторых должен быть компактен (как, например, тот же луа). В-третьих иметь стабильную историю подольше, чем у питона. В-четвёртых он должен быть меньше во всех смыслах. Питон тупо слишком большой.

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

Да я бы любую технологию поддержал в дефолте/стандарте больше чем CMake, вот буквально любое – Python (Meson, Waf), Lua (premake), Lisp, декларативное подмножество JavaScript (Qbs), сам JavaScript или Typescript и т. д.

Всё то, что позволяет нормально размечать сборочную логику, а не биться головой об ограничения и нелогичности CMake, порождая идиотические велосипеды для очевидных действий. И всё то, что позволяет расширяться без CMake-идиотии по типу «ну наш говённый DSL ограниченный, поэтому делайте find_package(Python3 REQUIRED) (реальная история я не тролль) и вызывайте вашу нормальную логику на Python».

https://premake.github.io/docs/Your-First-Script

Premake кстати выглядит максимально адекватно. Очень жаль что «крупный бизнес» выбрал именно CMake. Впрочем, не в первый и не в последний раз выбор IT-индустрии падает на откровенно отсталое, уродское и неказистое решение..

Что значит, никому не нужно? Понятно, что каждому конкретному проекту и 1й достаточно. Только вот проектов десятки тысяч, и у каждого своя специфика, свои языки, свои наборы поддерживаемых таргетных платформ, и тд.

В своё время большинство из этих десятков тысяч собиралось с помощью make. И ничего, не жужжали… :)

Стандарт на сборочную систему нужен. Преемственность важна. Никто при этом не запрещает пилить что-то своё нестандартное.

Да я бы любую технологию поддержал в дефолте/стандарте больше чем CMake, вот буквально любое – Python (Meson, Waf), Lua (premake), Lisp, декларативное подмножество JavaScript (Qbs), сам JavaScript или Typescript и т. д. Всё то, что позволяет нормально размечать сборочную логику, а не биться головой об ограничения и нелогичности CMake

Я понимаю твою фрустрацию из-за симейка. Меня тоже в нём очень многое не устраивает. Гибкости действительно не хватает, столкнулся когда свои генераторы кода внедрял. До сих пор нормально зависимости не отслеживает… Из того что пробовал, понравился базель, но только как идея, как язык. С практической точки зрения он не пригоден к массовому внедрению.

Ну так Premake не система сборки, а генератор. Как и Гугловская GN для их же Ninja. Кстати, в LLVM экспериментально давно добавили файлы GN, как альтернативу CMake.
И встроенная помощь в GN, пожалуй, одна из лучших в консольных утилитах, без man’ов. Разве что помощь в Fossil не хуже.

В своё время большинство из этих десятков тысяч собиралось с помощью make. И ничего, не жужжали… :)

В какое «своё»? Если 30 лет назад, так операционок было меньше и не требовалось пробировать наличие всего и вся. Да и альтернатива была - только автотулзы. Хотя и тогда, Иксы, емнип, собирались каким-то imake чтоль, в общем, чем-то своим. Так как они были максимально кросс-платформенные, и мейк им не подходил уже тогда.

Стандарт на сборочную систему нужен. Преемственность важна. Никто при этом не запрещает пилить что-то своё нестандартное.

Вы сами с собой разговариваете? Стандарт вы уже назвали - это мейк. Он есть и будет, никуда не отлучался. При этом, каждый пилит что-то своё, нестандартное. Всё как вы и пишете. Кому же вы оппонируете?

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

Да. Именно так, фрустрация от того что понимаешь что могли сделать хотя бы нормально. Как говорится «eсть два вида языков программирования: те, которые все ругают и те, которыми никто не пользуется», справедливо оно и для этих DSL. Мне вот в ближайшие месяцы нужно будет написать пару задористых Toolchain-файлов и CMake-модулей для экзотических компиляторов и архитектур (M-CORE, C-SKY), флажки которых не совпадают с GCC/Clang… И я уже предвкушаю сколько говна с лопаты я наемся пытаясь прикрутить ежа к ужу из-за отсутствия должной гибкости в CMake. В прошлый заход с другим экзотическим компилятором CMake постоянно пытался подсунуть мне какие-то захардкоженные GCC-флаги из своих кишок и обходил я это каким-то недокументированным способом. Кто знает, может сейчас это работать уже не будет.

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

А ты помнишь CMake времён 2.6 и 2.8? Был он пригоден тогда к массовому внедрению? Однако внедрили, не поморщились. Это сейчас его более-менее допилили до состояния «можно пользоваться с ощущением тяжести в желудке», а первых итерациях там были «стойкие рвотные позывы».

Как и Гугловская GN для их же Ninja.

Так а базель - всё? Что-то гугл шустро велосипедит слишком.

Ну так Premake не система сборки, а генератор

Так и CMake тоже. А QBS вообще гибрид, может и сам собирать.

Сегодня границам между системами сборки и генераторами/метагенераторами довольно размыта. Особенно если учесть что те же Makefiles порождаемые CMake дёргают бинарь cmake внутри себя и т. д.

У них, похоже, каждая команда пишет для своих рабочих проектов свою систему сборки – левая и правая рука. :)

Так и CMake тоже. А QBS вообще гибрид, может и сам собирать.

И CMake может собирать (хоть и вызовом внешних сборщиков), а Premake - нет, насколько я помню.

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

С пул реквестами есть несколько подходов и разные руководители в компаниях имеют разные предпочтения. Обычно переспорить их не получается и именно поэтому у меня возник вопрос о предпочтениях ЛОРовских программистов в этом.

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

Я работаю не один, хотя и в небольшой группе. Но мы не используем гитхаб или гитлаб, в которых реализованы пул реквесты. Собственно поэтому и возник вопрос, я подумал может быть это уже существует в самом гите. Погуглил немного, вроде нет, это к гиту не имеет отношения.

Я так тоже работал однажды и помню как несколько раз кто-то в команде приводил репозиторий к трудноустранимым проблемам.

Чистый git таки поддерживает пул реквесты, хотя и не такие, как в github/gitlab/etc. Почитай выхлоп man git-request-pull

А ты помнишь CMake времён 2.6 и 2.8? Был он пригоден тогда к массовому внедрению? Однако внедрили, не поморщились

Но энтузиазм-то был тогда какой! Как его встретили отлично! Не припомню чтобы кто-то сильно плевался. Мы тогда переползали с tmake (предтеча qmake на перле).

Чистый git таки поддерживает пул реквесты, хотя и не такие, как в github/gitlab/etc. Почитай выхлоп man git-request-pull

Почитал. Не знал что такая команда вообще есть, но в итоге-то всё равно надо делать слияние бранча с помощью всё той же команды git merge <ветка>. git-request-pull просто формирует удобный отчёт об изменениях для проверки.

Всегда надо делать слияние. В централизованных решениях вроде github это всего лишь автоматизировано. Мой вопрос был как раз таки про слиение, то есть как именно его делать.

Так и что ты имеешь против Python’а и любого другого нормального скриптового языка в качестве сборочной системы?

Напомню что meson.build пишутся не на Питоне, а на своём DSL языке, немного напоминающем Питон. Язык намерено сделан не Тьюринг-полным, там нет циклов и объявлений функций. Кодогенераторы и т.п. надо писать отдельно от Meson на других языках.

там нет циклов

А foreach? :)

А откуда дровишки? Я вот погуглил статистику - не нашёл. < Может ты какую-то видел?

Стопэ… так я не один, выходит, пропустил, что гит в этом релизе на мезон как раз и перешёл? Только сейчас заметил, что люди спрашивают «да где этот ваш мезон используется и кому он вообще нужен» в топике про то (в частности), что гит на него и перевели!

гит в этом релизе на мезон как раз и перешёл

Добавлена возможность компиляции системой сборки Meson.

Но и добавлено обоснование, что он круче мейка. А это, в общем то, почти равносильно тому, что перешёл, и что мейк начнёт там постепенно загнивать.

Всегда надо делать слияние. В централизованных решениях вроде github это всего лишь автоматизировано. Мой вопрос был как раз таки про слиение, то есть как именно его делать.

Тогда мой вопрос остаётся в силе, к какому пункту в твоём списке относится слияние с помощью git merge «ветка»? fast-forward merge?

Напомню что meson.build пишутся не на Питоне, а на своём DSL языке, немного напоминающем Питон. Язык намерено сделан не Тьюринг-полным, там нет циклов и объявлений функций. Кодогенераторы и т.п. надо писать отдельно от Meson на других языках.

И это правильно! Но тогда эта портянка из этого поста от Lrrr это не мезон, а просто питон скрипт?

Ну тогда переписать мезон на сях или плюсах не будет проблемой.

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

Меня только «import mesonlib» смущает. Это ещё зачем?

И это правильно! Но тогда эта портянка из этого поста от Lrrr это не мезон, а просто питон скрипт?

Это были исходники самого месона, вообще-то. Естественно что они на питоне. И выглядят они так себе. Например, грепнул по isinstance - 1595 вхождений. То есть, они послали полиморфизм нафиг, и везде пишут «если объект такого-то класса, то делаем это, а если сякого - то вот это». Код там крайне тяжело читать и править.

Это были исходники самого месона, вообще-то.

А, понял теперь что имел в виду Lrrr. Но там же в заголовке стоит

‘‘‘This module provides helper functions for Gnome/GLib related functionality such as gobject-introspection, gresources and gtk-doc’’’

То есть они в мезон вкорячили поддержку гнома? Да блин, что это, зачем?? Это как в симейк вшили поддержку qt, прямо в исходный код.

И выглядят они так себе.

Это ладно. Главная проблема в том что в систему сборки приходится добавлять код в таком количестве и такой запутанности для поддержки внутренностей какой-то библиотеки. Это вообще куда годится?

Не, такие «универсальные» системы сборки не нужны.

То есть они в мезон вкорячили поддержку гнома? Да блин, что это, зачем??

Так об этом он вам и твердил. Я лишь повторил сказанное. Вы могли этот же вопрос ему (Lrrr) задать ещё в самом начале. Ответ мне неизвестен. Видимо, предполагается, что где-то в параллельной вселенной все только и собирают модули для gobject-introspection и компилируют доки через gtk-doc, и по этому просто жить не могут без нативной поддержки таковых мезоном.

Вообще, у них идеология такова: «Мы не поддерживаем плагины и расширения. Мы не даём вам возможность делать макросы или подключать библиотеки рецептов. Но зато, вы можете закоммитить к нам в гит поддержку своего проекта, чтобы всё было, типа, искаропки». По факту, разумеется, такая привилегия доступна только тем, чей проект называется гном.

Так об этом он вам и твердил.

Я не заметил слово мезон в урле, увидел гном и подумал что это исходники гнома, а портянка это код который можно исполнять в мезон-файле. А на деле всё оказалось гораздо хуже…

Вообще, у них идеология такова: «Мы не поддерживаем плагины и расширения. Мы не даём вам возможность делать макросы или подключать библиотеки рецептов. Но зато, вы можете закоммитить к нам в гит поддержку своего проекта, чтобы всё было, типа, искаропки». По факту, разумеется, такая привилегия доступна только тем, чей проект называется гном.

Может быть там можно эти модули подключать на лету? Типа таскать такой модуль с проектом вместе? Всё равно ничего хорошего конечно, но хотя бы видимость гибкости.

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

Аа, ну так я вам компенсирую данное упущение: https://gitlab.gnome.org/GNOME/glib/-/blob/main/meson.build

Это то, что вы просили? Слова «мезон» в урле теперь нет.

Может быть там можно эти модули подключать на лету? Типа таскать такой модуль с проектом вместе?

Я ж вам говорю, нельзя ни модули подключать, ни даже какие-либо пользовательские библиотеки макросов создавать. Вообще ничего подключать нельзя. Вместо этого, их девиз - «всё искаропки, комитьте все расширения в наш гит». Но этот девиз работает только для гнома. Что вам и показал Lrrr

Я ж вам говорю, нельзя ни модули подключать, ни даже какие-либо пользовательские библиотеки макросов создавать. Вообще ничего подключать нельзя. Вместо этого, их девиз - «всё искаропки, комитьте все расширения в наш гит». Но этот девиз работает только для гнома. Что вам и показал Lrrr

Тогда вообще не понимаю восторга от мезона. Это же фу.

Тогда вообще не понимаю восторга от мезона.

А где вы его видели? Восторга и нет. Пользуемся тем, что дают. Обвешиваем его баш-скриптами. Работать надо, а не восторгаться.

И, кстати, зря вы не посмотрели тот урл, что я кинул. Это же эпично. Чел руками делает за мезона все проверки. То, что в автоконфе делается 1 макросом, тут делается созданием тестовой проги и запуска компилятора в явном виде, чтобы проверить результат. То есть, мезон не помогает, а скорее мешает этому процессу.

Да я посмотрел, я думаю это есть configure переписанный на мезоне.

Тогда мой вопрос остаётся в силе, к какому пункту в твоём списке относится слияние с помощью git merge «ветка»? fast-forward merge?

Зависит от твоих настроек. По умолчанию git merge «ветка» пытается сделать fast-forward, а когда это невозможно делает мерж коммит.

Пользуемся тем, что дают.

Есть же cmake, который хотя бы не на питоне. Ну и ещё десяток альтернатив…

Да я посмотрел, я думаю это есть configure переписанный на мезоне.

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

Есть же cmake, который хотя бы не на питоне. Ну и ещё десяток альтернатив…

Да вы хоть понимаете, сколько времени отжерает копание в каждой из этих «альтернатив»? Сразу ведь не поймёшь, надо портануть несколько проектов, чтобы хоть мельком оценить, подходит или нет. В результате, берут то, что развивается, на что все переходят, где много документации и презенташек, и где синтаксис более-менее вменяемый. Ну я ещё xmake копнул - это сразу отпадает, там и смотреть нечего. Но другие-то системы все надо ОСВАИВАТЬ! У вас есть месяца 2 времени на освоение десятка систем сборок? Или проще с мезоном побадаться?

Да вы хоть понимаете, сколько времени отжерает копание в каждой из этих «альтернатив»?

Если нет времени, то есть симейк, который на сегодня это «стандарт» де-факто для сей и плюсов, есть ещё автотулзы. Для того чтобы выбрать что-то альтернативное должны быть очень веские основания.

Для того чтобы выбрать что-то альтернативное должны быть очень веские основания.

У мезона неплохой синтаксис, много документации и куча хайпа (презенташки на ютубе, новости о том, что очередной гит на него перешёл, и всё в этом роде). Этим они и ловят новичков, типа меня. Конечно, тот факт, что, по определению, нет никаких возможностей расширения (ни самой системы сборки плагинами, ни конкретной пользовательской сборки библиотеками макросов) отпугнул бы более искушённого в этих вопросах человека. Но они так убедительны в своих презенташках, когда говорят «нафига что-либо расширять, у нас всё искароппки», что люди верят. :)