Опубликован релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.27, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. CMake примечателен предоставлением простого языка сценариев, средствами расширения функциональности через модули, поддержкой кэширования, наличием инструментов для кросс-компиляции, поддержкой генерации файлов сборки для широкого спектра систем сборки и компиляторов, наличием утилит ctest и cpack для определения сценариев тестирования и сборки пакетов, утилитой cmake-gui для интерактивной настройки параметров сборки. Код CMake написан на языке C++ и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59481
Какие достоинства и недостатки у этой пары?
Начнем с того, что это взаимоисключающие инструменты.
Не совсем. Как минимум у Meson есть модуль-транслятор CMake ( https://mesonbuild.com/CMake-module.html ), который позволяет выполнять сборку CMake подпроектов прямо из Meson (в идеале, даже не меняя ничего в исходном скрипте CMake-а) и разрешать зависимости с помощью cmake-а.
Первое -- перегруженное легаси с нарушениями совместимости из-за чего сборочные скрипты постоянно отваливаются и пойди разберись из-за чего, сомнительным синтаксисом и документацией, вызывающей определённые вопросы. Второе впихнёт в тебя весь гномовский кал и простым исправлением сборочного скрипта, как с autotools, тут не обойдёшься, но лучше ничего не придумали.
Понимаю твои страдания, связанные с несовместимостью и сложностью синтаксиса в cmake. Однако, мне довольно сложно сопереживать твоему опыту, так как мои собственные взаимодействия с этим инструментом не вызывали таких проблем. Возможно, это связано с разными подходами к использованию cmake или различиями в наших проектах. Несмотря на все трудности, всё-таки cmake остаётся одним из самых мощных и гибких инструментов для сборки проектов.
Сколько у тебя того опыта? В этом всё дело. Через несколько лет забвения сборочные скрипты тупо разваливаются.
как и все остальное в it.
либо адаптируется, либо отправляется в архив - третьего не дано
Скоро будет 5 лет проекту на Meson кодовая база ~100_000 строк,
но только патчи и правки. В остальном не трогает никто.
Через несколько лет почти любой код разваливается, если его не трогать, библиотеки обновляются, интерфейсы меняются, код перестает собираться. Мы в шутку называем это периодом полураспада кода. Cmake редкостная дрянь, но ничего лучше на данный момент нету. Autotool может быть и хорош для сборки, но сборка это одна из из функций которые нужны. Система сборки это инструмент разработчика. Идея о том что пользователи будут устанавливать пакеты из исходников - это утопия. Смысла она особого не несет. А вот проблемы разработчиков Cmake решает гораздо лучше Autotool. Как минимум тем что есть интеграция в среды разработки. Интеграция в пакетные менеджеры: vcpkg и прочие. Жизнь с++ разработчика с приходом Cmake стала значительно лучше. И де факто это сейчас является стандартом.
В том и дело, autoreconf прогоняешь и всё собирается дальше на новой версии, как и собиралось. Есть куча проектов, десятилетиями не менявших сборочные скрипты, и у них по-прежнему всё в порядке при сборке в современных системах. Что касается зависимостей, то тот же pkg-config дохнет куда реже сомнительных скриптов. Если совместимость в библиотеке есть, то она никуда не денется, а на нет и суда нет. Но это другой уровень забот и cmake просто справляется с этим хуже.
> В том и дело, autoreconf прогоняешь и всё собирается дальше на новой версии, как и собиралось.В этом месте автотулс педальный и правда всех делает с отрывом. Что-что а пересобрать новую программу на олдовой системе, или олдовую программу на свежей системе - обычно прокатывает.
С cmake это будет 50/50. А с мезоном - как обычно с всей питонятиной, через пару лет оно вообще уже не совместимо с собой. А система конфигурации/сборки это оно. И не должно становиться источником проблем хуже чем собираемый, блин, код и требовать постоянного внимания. Потому что тогда получается что хвост виляет собакой.
Вы по прежнему не поняли смысл. Взять и собрать приложение это одна задача. СОВСЕМ другая задача это разрабатывать приложение, именно обеспечивать сборку для процесса разработки. CMake это не система сборки. Это генератор проектов, это система описания проекта для разработчика, не для конечного потребителя. В процессе разработки возникает все время вопрос как сделать так что бы с твоей пачкой исходников люди могли работать на разных системах и в разных IDE для разработки. Именно разработчики, пользователи в этой схеме вообще отсутствуют. К ним прилетит готовый бинарь. Собирать приложение из исходников надо 3-ем красноглазым з@дротом на планете. Для установки и менеджмента приложений давно придумали пакетные менеджеры. А разрабатывать приложение нужно армии программистов, которые порой работают не только с c++. Cmake это не система сборки, это генератор проектов, или система описания проекта. Даже автор новости не понимает зачем и что нужно. Именно поэтому Cmake будет жить и развиваться. А аутотул сдохнет как система сама в себе которая непонятно зачем существует.
Не выдумывай, я говорил именно про разработку. Но сборка это часть процесса разработки.
>Жизнь с++ разработчика с приходом Cmake стала значительно лучше.А насколько бы она стала лучше с уходом С++...
Не перестаю поражаться тому хроническому ужасу из соплей костылей и палок который терроризирует мир айти по вине сишников.
Это же нужно было так фундаментально испортить всё вообще.
> Не перестаю поражаться тому хроническому ужасу из соплей костылей и палок который терроризирует мир айтиСправедливости ради, это существует в основном в коммерческой разработке.
Когда на пятки наступают конкуренты, то либо работаешь с тем, что есть, либо твой бизнес вымирает от траты временни и денег на улучшения, которые не принесли конкурентных преимуществ.
С/C++ сильно усложняет разработку, делая её не просто дорогой но и недоступной для небольших бюджетов.При этом С++ активно продвигал конкретно майкрософт.
То что гемдев в массе это виндовс + С++ как бы не совпадение.Сишка уж очень выглядит как саботаж индустрии.
> autotools
> лучше ничего не придумали.Только вот оно прибито гвоздями к unix-окружению. А сабжы пытаются быть кросс-платформенными.
> Только вот оно прибито гвоздями к unix-окружению. А сабжы пытаются быть кросс-платформенными.Только это окружение можно и в винде вкатить. И если на то пошло автотулс работает в большем числе всяких странных окружений чем вон те вместе взятые. Уж мезон вообще настолько "кроссовый" что кроме винды линя и мака на целых полутора архитектурах - по сути ничего и не умеет. И уж не ему про кроссовость вещать.
> Только это окружение можно и в винде вкатить.А поддержку MSVC в автотулз тоже вкатишь?
> Какие достоинства и недостатки у этой пары?обычные болгеносы - в ядре Linux по прежнему make
Что не является преимуществом ни ядра, ни мейка.
> Что не является преимуществом ни ядра, ни мейка.Linux использует 100% населения земли поэтому он нужен как воздух а с ним и make, а кому нужен cmake и meson кроме пары широкоизвестных в узких кругах проектов? "лучше гор могут быть только горы"
Не понимаешь смысла и назначения Cmake и Make. Cmake это в первую очередь инструмент разработчика. Как Autolool решит проблему работы в Visual Studio, XCode, Clion и QtCretor под Win, Mac, Linux одновременно команды разработчиков? А это реальность в которой живу уже который проект подряд.
> Как Autolool решит проблему работы в Visual Studio, XCode, Clion и QtCretor под Win, Mac, Linux одновременно команды разработчиков?для сборки Linux не нужен Autotool - как же работают над ним одновременно сотни тысяч разработчиков по всему миру?
> для сборки Linux не нужен AutotoolПотому что у них есть собственный Kconfig/Kbuild.
> Потому что у них есть собственный Kconfig/Kbuild.он конфигурирует само ядро а не собирает информацию о системном окружении - ядро самодостаточный проект, в отличие от болгеносов где на каждый чих тащат внешние библиотеки
>> Потому что у них есть собственный Kconfig/Kbuild.
> он конфигурирует само ядро а не собирает информацию о системном окруженииТак и autotools/cmake/meson нужны для того, чтобы конфигурировать сборку проекта под конкретное окружение. Соответственно и данные об этом окружении надо собрать (для ядра конкретно этого не надо, тут согласен).
> Соответственно и данные об этом окружении надо собратьдля болгеносов. Если проект самодостаточный - нет, поэтому достаточно обычного make, kconfig вообще не аналог autotools/cmake/meson - он конфигурирует внутреннюю структуру проекта.
> Linux использует 100% населения земли поэтому он нужен как воздух а с ним и makeСкайнет совсем не палится :)
А никого не смущает, что это замены autotools, а не make-а?
Cmake умеет работать и с make-ом напрямую. Meson исходит из того, что проще простую, как валенок, ninja (вот это, как раз, альтернатива make) собрать под нужную платформу, чем писать отдельный генератор ещё и под make https://mesonbuild.com/FAQ.html#why-is-there-not-a-make-backend
meson проще, быстрее, неплохо документирован для начала работы. По факту, не является системой сборки. На деле высокоуровневый конфигуратор для системы сборки ninja. Позволяет очень быстро подготовить сборку своего проекта, но трудно кастомизируется, если нужно что-то нетривиальное. ИМХО наркоманское исполнение subproject. Для линковки необходимых библиотек иногда нужно долго подбирать их название, удовлетворяющее meson. Используется проектом mesa3d.
Сmake сложен для освоения, многословен, ужасная документация, однако содержит кучу возможностей для кастомизации сборки под свои потребности. По факту, сейчас является самой распространенной системой сборки (даже учебники по нему видел).
Корпораты по своим личным гендерным причинам нее переносят autotools. Ядро Линукс как-то собирается и ничего. А у этих не получается, практически со студенческой скамьи начинают сборочные системы строгать.
Кто о чем, а вшивый о бане...
В ядре Linux autotools не используется. Вообще, autotools - это груда костылей на никому не известных язычках вроде M4 кишками наружу - у авторов не было никакого понятия об инкапсуляции. Сравнивать его "архитектуру" можно только с CVS.
> на никому не известных язычках вроде M4m4 is a general-purpose macro processor included in most Unix-like operating systems, and is a component of the POSIX standard. First appeared 1977; 46 years ago
CMake точно также можно называть костылем. Особенно учитывая такое явление, как modern cmake.
>не известных язычках вроде M4это прородитель всего сущего... RTFM LMD!
Да нахрен такие прородители? Я помню что даже sendmail.cf предпочитал руками писать (да-да, все эти правила чтобы почту от спамеров и прочих кулхацкеров фильтровать), лишь бы с этой хтонью не связываться.
Кто знает, поддерживает ли Cmake модули в C++?
Точно поддерживает модули Fortran. Модули C++ вроде пока работают в экспериментальном режиме.
https://github.com/Kitware/CMake/blob/master/Help/dev/experi...
Спасибо большое за новость! Сам использую и то и то. Недавно читал новую статью про настройки CMake https://habr.com/p/741868/