Кто-нибудь пробовал build2?

Я как-то тыкал. Оно навязывает своё виденье организации проекта, с которым не поспоришь и которое мне не понравилось, так как неудобно. Команды и скрипт тоже показались несколько замороченными.

Then the actual versions of the dependencies present in the build configurations are recorded in the project’s lockfile so that if desired, the build can be reproduced exactly. The lockfile functionality is not yet implemented.

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

Всё лучше, чем CMake (кроме Autotools, он хуже).

Всё лучше, чем CMake

И чем же?

Аutotools - лучшее, что придумали для сборки свободных проектов

А есть в природе туториал для человеков по автотулзам?

$ info autoconf

Зачитаешься.

Изначальным продумыванием архитектуры и DSL.

https://autotools.io/

ну и официальные мануалы

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index...

http://www.gnu.org/software/automake/manual/automake.html

топикстартеру тоже полезно будет

Всё лучше, чем CMake

И чем же?

Проблема в том, что, как правило, опенсорсню собирают ретрограды, которые бы вообще всё писали на баше и сях, потому их не волнует тот факт, что autotools отстал от прогресса лет на 20, и уже не вытягивает современные требования по гибкости и скорости работы. По этой причине за последние 20 лет как грибы после дождя возникли отдельными островками самые разные наколенные инструменты для конфигурации/сборки: Meson, SCons, CMake, Bazel, Qbs, QMake. И ни одна из них не собрала достаточно внимания и ресурсов. чтобы быть хорошо проработанной.

https://www.reddit.com/r/programming/comments/9gtz7q/do_not_use_meson/

Do use meson. Or bazel. Or scons. Or buck. Anything better than CMAKE.
I still cannot comprehend how come cmake, the most popular C++ build system of 2018, is so bad. For example, in most projects, all variables are global; function results are communicated by global variables; referencing non-existing variables is not an error; looking up variables by dynamically-generated name is normal practice and so on.

I still cannot comprehend how come cmake, the most popular C++ build system of 2018, is so bad. For example, in most projects, all variables are global; function results are communicated by global variables; referencing non-existing variables is not an error; looking up variables by dynamically-generated name is normal practice and so on.

Ну в общем, да.

главная проблема музыки в россии (c)

Проблема в том, что, как правило, опенсорсню собирают ретрограды, которые бы вообще всё писали на баше и сях, потому их не волнует тот факт, что autotools отстал от прогресса лет на 20, и уже не вытягивает современные требования по гибкости и скорости работы.

Ну так напишите же альтернативу, ёпта.

Ой, я забыл. Нормальных альтернатив от инди-разработчиков — овердофига. Но сообщество будет жрать тьюринг-неполное говно meson от корпораций.

Сообщество само этот путь себе заслужило. Приятного аппетита.

на баше

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

Чтобы пользоваться cmake, нужно вообще быть упоротым в хламину.

Спасибо, конечно. Но я лучше сразу на sh и m4 нахерачу — там по крайней мере, есть язык программирования. Не фонтан, конечно, но лучше, чем ничего.

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

Примеры бы еще посмотреть…

Ни одного проекта не видел чтобы собирался этой вундервафлей, зато видел на bazel. Имхо 146% не взлетит.

1. Глобальные переменные. Да, используются. Ну и что с того? Чем это плохо? CMake что будем оценивать с позиции высокоуровневых ЯП? Функции могут создавать глобальные переменные в качестве результата - да и что? Вывод: это плохо. Где аргумент в пользу того, что глобальные переменные в CMake - это плохо?
2. Можно проверить переменную на существование - в чем проблема.
3. Динамическое генерирование имен переменных и использование их - опять, где аргумент, что это плохо? Или это плохо само по себе, потому что автор сего изречения так захотел?
4. И так далее. - Что «и так далее», не люблю такие фразы в качестве многоточий.

Это теория и dsl - это весьма размытое понятие. Я бы лучше послушал аргументы более приближенные к практическим ситуациям и возможно привел бы свои аргументы.

Вот поэтому в моих проектах waf.

Питона хотя бы два, чем реализаций POSIX shell-ов. И не такое страшное как m4.

Впрочем meson тоже вполне нормальный, когда он не твоя головная боль.

Системы сборки не нужны. Или ручками прописанный Mаkefile или аналог самопальный. Все зависимости должны быть доступны опционально локально даже если их не существует на платформе, а если существуют то это и так известно где их искать и как брать, но при этом всё должно быть задокументированно, а не получено в виде пустого выхлопа системы сборки «missing/broken depend». Ни одна система сборки на данный момент не решает проблемы сборки полностью автоматически, а уровень возни в проектах выше приветмира больше чем ручное описание под конкретную версию конкретной платформы. Исключение это высокоинтегрированные системы в рамках полатформы. Автотулза на юниксподобных, но шаг в сторону и всё. цмаке ужас вообще без разговоров. Мезон, смехотворен ибо прибито гвоздями всё настолько что чуть в сторону и гг. Нинзя убога. Makefile золотая середина. Свой лесопед для проекта часто самое адекватное решение.

В целом согласен.

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

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

Существенный недостаток — то, что она всё компилирует в один файл.

Если бы она просто клала в ./build-aux/ все необходимые ей файлы с функциями, а ./configure оставляла более-менее чистым, который инклудид свои стандартные скрипты, а не копипастит их целиком, то было бы проще всё это поддерживать.

Можно было бы подменять часть ./build-aux/-а на лету, например. Если дефолтные скрипты не годятся для платформы.

Вот хоть бери и переписывай нормально…

Кстати, X512

Отличный взгляд. ЯП тоже не нужны, кроме assembler-a.

цмаке ужас вообще без разговоров

Отличный аргумент вообще без разговоров и аргументов.

пакетный менеджер

В ад, пусть там горит. Хватит миру пакетных менеджеров.

Makefile золотая середина.

Есть ещё rake.

Да пожалуйста:

1. За что так не любят cmake? (комментарий)

2. Оценки хелловорлда тред (комментарий)

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

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

Самый прикол в том, что т.н. гибость сборочной системы скорее не нужна чем нужна. Кому нужна гибкость, как говориться, пусть и парится. Ни у Го-, ни у Раст-, ни даже у, мать её, nodejs-разработчиков нету головняков со сборкой и импортом. У Ruby, аналогично, есть подход с ruby gems.

И только C/C++ -разработчики в своей ретроактивности могут спокойно пожирать 10 000 сортов разнообразного шлака и с него же блевать на форумах. При этом объяснять им, что собака зарыта немного южнее, нет никакого смысла. Вообще.

P.S.: кстати мэйнтейнеры дистров (уже в своей ретроактивности) внесли в это дело не малую лепту от себя. Решив, что это они решают где и чему лежать. Что добавляет сразу 100 очков кретинизма каждому из них.

сборочная система

Ruby с ruby gems

Ловите наркомана!

С точки зрения разработчика система сборки waf – классная. Она требует лишь Python 2 или Python 3 и не требует никаких дополнительных пакетов для сборки, как тот же CMake или Meson. А Python сегодня de-facto стандарт скриптописания и имеется на любой девелоперской тачке.

Как я понимаю, у waf имеется некий wrapper, который и позволяет собирать код сразу после клонирования его из репозитория без установки всяких дополнительных пакетов. Современные системы сборки в той же экосистеме Java: Gradle и Maven такое давно практикуют, там для сборки требуется лишь установленный JDK, а в случае с waf – Python + требуемые для проекта зависимости. Это такое же преимущество, как и у подхода autotools с configure-скриптом. Только вместо вырвиглазной нечитаемой лапшевидной портянки на shell/m4 и смеси ещё какого-то дерьма в куче файлов и таких же напрочь кривых, генерированных и тормозных Makefile – у waf стройная и понятная архитектура с нормальным языком описания сборки.

Многие говорят, мол полноценный язык для описания сборки это плохо и из пушки по воробьям. Но как только требуется собрать что-то сложнее Hello World и шагнуть в сторону от их уютного DSL, как тут же начинаются проблемы и нытьё на форумах «а как мне зделоть в смаке такое??», DSL, если он не является подмножеством полноценного языка, ограничивает и вставляет палки в колёса в различных нетривиальных случаях.

Да и вообще изучать ещё один DSL язычок для того, чтобы просто внедрить в проект сборочную систему – ИМХО, только мусор в голову класть. Особенно ковыряясь в различных упоротых доках того же CMake с кучей mindfuck’ов. Но стоит помнить, что DSL’ы как могут быть откровенно наркоманскими, спроектированными макаками без зачатков мозга, как в случае с CMake, более-менее приемлимыми, как в случае с Meson или откровенно декларативными с возможностью расширения, как в случае с QBS. Весь этот зоопарк в экосистеме C/C++ не от хорошей жизни, а от отсутствия понятия модулей, которые вот уже несколько лет всё пытаются внедрить, но воз и ныне там.

Из cons у waf разве что можно придраться к использованию Python, который много кто недолюбливает. Но факт остаётся фактом, сегодня он очень широко распространён, гораздо шире того же Shell’а, например. Возможно ещё какое-то значение имеет GIL в нём, при параллельной сборке наверное GIL как-то сказывается, но мне не хватает опыта работы с waf, чтобы это заявить утвердительно. По личному опыту я могу сказать, что обычный make + Makefiles в многопотоке тормозные, а Ninja отрабатывает на 10-15% быстрее. А waf, как и qbs вызывает компиляторы напрямую.

В идеальном мире возможно место waf занял какой-нибудь nim-build, на Nim или похожем языке программирования. С дешёвыми потоками, статической типизацией и возможностью компиляции в нативный код. Но в нашем мире сначала выиграло откровенно наркоманское решение – autotools, а на смену ему пришло практически такое же наркоманское в лице CMake. Что же, хорошо что в мире IT всё очень быстро меняется, возможно языки С и C++ спустя годы получат наконец достойную систему сборки, а файлы configure и CMakeLists.txt отправятся в /dev/null из наших репозиториев и репозиториев других разработчиков.

Так что waf всяческих успехов в популяризации. Возможно он или его идейный наследник когда-нибудь сотрёт с лица земли этот позор сборочных систем мира Unix и C/C++: как Autotools, так и CMake.

Глобальные переменные. Да, используются. Ну и что с того? Чем это плохо? CMake что будем оценивать с позиции высокоуровневых ЯП? Функции могут создавать глобальные переменные в качестве результата - да и что? Вывод: это плохо. Где аргумент в пользу того, что глобальные переменные в CMake - это плохо

Проблема не в том, что есть глобальные переменные, а в том, что абсолютно все операции идут через них. То есть, по мере роста сложности конфигурялки она становится нечитаема и неподдерживаема. На этом фоне тот же Python выглядит намного аккуратнее, при всем моем неуважении к питону.

Как напишешь - так и будет. Если не херачить все в одном файле, а разбивать на отдельные cmake-и и поддиректории, то можно делать вполне аккуратно.

Про поиск SDL. С одной стороны - это проблема авторов библиотеки сделать скрипт cmake для поиска себя. С другой стороны для поиска SDL И SDL_image через CMake я использовал модуль CMake FindPkgConfig, файлы для pkg-config в составе SDL и SDL_image есть.

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

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

Но факт остаётся фактом, сегодня он очень широко распространён, гораздо шире того же Shell’а, например.

Ловите наркомана, на какой кофеварке не стоит sh?

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

Есть мини-интерпретатор питона, довольно годный… как бишь его… забыл название. В общем, он поддерживает довольно большой кусок питона 3, но всё-таки не на 100% совместим.

Если бы такие проекты, как этот waf или тот же meson разрабатывались с прицелом на совместимость с таким интерпретатором, у меня бы осталось только возражение против тьюринг-неполноты meson, а против waf вообще бы не осталось.

Только вместо вырвиглазной нечитаемой лапшевидной портянки на shell/m4 и смеси ещё какого-то дерьма в куче файлов и таких же напрочь кривых, генерированных и тормозных Makefile

Тут есть разумная мысль: автотулзам исходно не очень-то нужны были Makefiles. Можно сразу херачить правила на m4, а потом транслировать на этапе конфигурирования проекта их хоть в Makefiles, хоть в ninja, хоть куда.

К сожалению, хорошая мысля приходит опосля. В 90-х это всё было далеко не очевидно.

Что касается m4, ты просто не умеешь его готовить. Ну а sh, к сожалению, всё еще настолько же безальтернативен, насколько убог.

С одной стороны - это проблема авторов библиотеки сделать скрипт cmake для поиска себя.

У авторов библиотеки нет никакой такой проблемы. Всё, что нужно, лежит здесь:

$ cat /usr/lib/pkgconfig/SDL2_image.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: SDL2_image
Description: image loading library for Simple DirectMedia Layer
Version: 2.0.5
Requires: sdl2 >= 2.0.8
Libs: -L${libdir} -lSDL2_image
Cflags: -I${includedir}/SDL2

То, что cmake страдала NIH-синдромом — её личная проблема.

За что так не любят cmake? (комментарий)

1. Можно проверить существование переменной.

2. Можно вызывать во втором случае так: cmake . -DSDL=no

3. Не понял про вызов функций. Можешь подробнее?

4. Так Makefile-ы же на выходе и проект под Visual studio тоже умеет. Не?

5. Не знаю, не пробовал.

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

Ха. Так я же написал, что CMake может напрямую работать с pkg-config.

Ловите наркомана!

По тоему ruby проекты не собираются в пакеты? Пожалуй я отвечу тебе – твоими же словами. (Хотя скорее – ловите ретрограда).

У ruby там собираются компилятором только расширения на си.

Всё остальное, представь себе, обычный ruby.

Ну и экосистема ruby божественна. RVM превосходно решает вопрос DLL hell, который в дистрибутивах линукса за 25 лет решить не смогли.

Хоть бери и вообще всё переписывай на ruby просто ради возможности использовать RVM.

Проблема с CMake в том, что они обосрались в своих обещаниях и пошли обратно, перестали поставлять Find-модули, хотя изначально поставляли.

В итоге дистрибутив CMake-теперь состоит из заскорузлых древних модулей, а прикладные разработчики, как последние виндузятники лазят по GitHub’ам и собирают мокрые письки: [1], [2], [3], [4], [5] тысячи их. Какой из них правильный и корректный? Может ты мне скажешь? Бгг.

проблема авторов библиотеки сделать скрипт cmake

Хм. Это звучит точно так же, как аргумент Matthias’а Clasen’а, одного из авторов скатывания GNOME:
https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_356808

Проблема в том, что CMake-разработчики решили что весь мир вращается вокруг них и все роняя на бегу код побегут создавать Find-модули к собственным либам. А этого не случилось. И даже ума предложить юзерам создать поддерживаемый ими же репозиторий с подобными Find-модулями у них не хватило.

Собственно, скатертью дорога. Не зря Red Hat выбрал Meson для GNOME, X.Org, Wayland, Mesa и кучи всего Linux’ового.

А можно просто не использовать эту CMake-наркоманию, а использовать более адекватную систему сборки, что разработчик на пост которого я сослался в итоге и сделал.

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

Ловите наркомана, на какой кофеварке не стоит sh?

Какой из? Их целый зоопарк развёлся и отношения у них друг с другом как у мужа с тёщей.

С другой стороны – Python-зоопарк и ахинея 2to3 тоже не лучше, хотя вторая ветка потихоньку отмирает, слава и позор Гвидо. Особенного смака этот маразм получил в «ынтерпрайных» дистрах вроде RHEL 8, где могут сосуществовать целых три пайтона вместе. Один третий тебе нужен для DNF, он системный и обновляется отдельно от того, обычного Python 3, что используется при прикладной разработке. А когда ты ставишь какой-нибудь Mercurial, вот оно тянется и второй.

Какой из? Их целый зоопарк развёлся и отношения у них друг с другом как у мужа с тёщей.

На практике выхлоп автотулзов запускается на всех юникс-подобных архитектурах, какие остались в ходу.

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

Вот, кстати, и идея для очередной вундервафли:

• В качестве основы использовать язык с гомоиконной основой более мощный, чем m4.
• Транспилировать сборочный рецепт в переносимый sh-файл. Полностью скрыть от программиста конструкции sh за синтаксисом этого языка. Траспилятор реализовать на самом же этом языке. Пусть рецепт сам себя транспилирует.
• Основной массив инклудов не инклудить жестко вставкой в тело ./configure, а класть в ./build-aux/, и из ./configure инклудить средствами самой sh.
• Правила писать не на make, а на том же языке. При выполнении ./configure строить на их основе makefile (без рекурсивных вызовов make, слава Аллаху) или любые другие синтаксисы описания зависимостей по выбору.

Итого сохраняем все преимущества автотулзов с устранением всех основных недостатков.

Насколько я помню, это проблема старого CMake.

Подробнее расскажет a1batross

Видать какой-то очередной mindfuck похожего уровня упоротости: https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake

Не вчитывался, но судя по ответу, cmake изобрела sh. Экранируйте всё, или всё развалится…

Ну хоть видов кавычек не 10 штук и на том спасибо.

1. А что если ты опечатался? Ну вот со всеми бывает. Любой нормальный интерпретатор/компилятор скажет, что переменной не существует. Тот кто получше скажет, что вы и опечатались и предложит замену.

2. Но зачем? Зачем CMake вообще нужен кэш?

3. Не знаю куда ещё подробнее. Аргументы разделяются пробелом. В этом и проблема.

4. Это придирка немного натянутая на самом деле. Меня она мало смущает, но приходили люди, которые не хотели устанавливать CMake, но хотели открыть проект в Visual Studio. И для них нет возможности нет сгенерировать проект, который бы не требовал наличия CMake в системе. Странная вещь, я с нею не согласен, это не мои хотелки.

5. Зря. Как только поймешь кросскомпиляцию, везде захочется использовать. Не каждая железка может с адекватной производительностью компилировать код, поэтому это очень крутой скилл.

6. Да, эта придирка тоже со временем устарела. В любом случае код для системы сборки с учётом кроссплатформенности получается полон условий под каждую платформу и это не вина CMake.

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

Да нет, она кажется вполне себе логичной.

Взять тот же Autotools, он ведь не требует наличия в системе m4 и прочих autocrap’ов вроде automake или autoconf.

Разработчик при подготовке релиза просто рожает с помощью этих утилит автономный нечитабельный Shell-скрипт чудовищного размера, который другие разработчики будут запускать на своих тачках предварительно перекрестившись три раза и помолившись, чтобы случайно незаэкранированный пробел не выполнил им rm -Rf ~/. Думать о таком вот зоопарке autocrap’ов: https://aur.archlinux.org/packages/?O=0&SeB=nd&K=automake для протухших сборочных описаний прикладному разработчику, который решил собрать твой проект или библиотеку, по идее не нужно.