понедельник, 16 октября 2023 г.

[prog.c++.kill-them-all] Во что обходится это дерьмо, CMake?

Сегодня наткнулся на блог пост "The road to hell is paved with good intentions and C++ modules", создателя Meason-а. А в этом блог посте ссылку на вот эту презентацию: "A new CMake Scripting Language?". Из которой можно узнать интересные цифры. Например, перевод некого проекта Trilinos с GNU Autotools на CMake обошелся Sandia National Laboratories (SNL) более чем в миллион долларов -- около $500K составила стоимость рабочего времени сотрудников SNL и еще около $700K было потрачено на контракты с Kitware по доработкам CMake/CTest/CDash.

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

Но вот после знакомства с вышеупомянутой презентацией я вообще в шоке.

Это как же у Kitware получилось сперва выкатить откровенное дерьмо в мир, затем убедить кучу народа это жрать не просто причмокивая, а еще и доплачивая Kitware?

Снимаю шляпу.

Пару лет назад я был готов добавить в RESTinio поддержку HTTP-клиента за $3.5K (что на тот момент не превышало одной месячной ЗП C++ разработчика моего уровня, причем просто чистой ЗП, без налогов на ФОТ и прочих издержек). А тут создатели CMake не стесняются озвучивать сумму в миллион долларов для того, чтобы сделать улучшенный CMake.

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


Отдельно мне доставила фраза со слайда #11 в упомянутой презентации:

The book “Professional CMake” largely solves the CMake Documentation problem.

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


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


Говорил раньше и повторю еще раз: если собрать список причин по которым стоило бы распрощаться с C++, то CMake там был бы на одном из первых мест.

И не потому, что CMake плохой. Плохого софта не так уж и мало.

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

6 комментариев:

  1. Скажите, пожалуйста, пробовали другие системы, не cmake? build2, meson? Чем-то лучше?

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

    В середине 2000-х попадались кроссплатформенные приложения в исходниках. Там для MSVC++ свой cmd для запуска билда, потому что свой формат make и так далее. На этом фоне Cmake, возможно, решал проблему.

    Не ради флейма, не знаю, удалось ли кому-то решить это иначе.

    ОтветитьУдалить
  2. @Alex: я давным-давно пользуюсь своей самодельной системой сборки. Она развивалась где-то с 1996-го, прошла несколько поколений (не совместимых между собой) и с 2004-го года она носит название Mxx_ru (MxxRu). Документацию (немного устаревшая) по ней можно посмотреть здесь. Пример использования -- в SObjectizer или arataga. Все эти build.rb, build_all.rb, prj.rb... Это все на собственной системе, написанной где-то за месяц-полтора. Потом чуть-чуть допиленной, но не принципиально.

    При этом MxxRu -- это действительно система сборки, а не генератор make/ninja/.vcproj файлов.

    Развиваться, правда, уже не будет. Не потяну я добавленные в C++20 модули :(

    ОтветитьУдалить
  3. Чорт побери! (c), как я мог забыть :) Были статьи в RSDN про эту систему + ваш подход к организации зависимостей между проектами на основе subversion. Но с cmake, тем не менее, вам приходилось сталкиваться, а с другими из списка - нет?

    Оффтопик - вы ведь переехали в git? Бранчи в духе git flow используете? Или что-то ближе к trunk а-ля svn?

    В чём-то увидели преимущества git как нового инструмента? Меня в своё время подкупила полная локальная история проекта (без необходимости интернета), хотя и нужно было крайне редко.

    ОтветитьУдалить
  4. > Но с cmake, тем не менее, вам приходилось сталкиваться, а с другими из списка - нет?

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

    Пока очень спасает то, что на данный момент для наших собственных проектов у нас CMake -- это просто резерв, основная разработка идет через MxxRu. Хотя вот сейчас пытаемся делать следующую версию RESTinio (очень не быстро пытаемся) и там уже MxxRu нет, только CMake, т.к. Catch2 v3 используемая у нас для unit-тестов уже не header-only и собрать ее через CMake как два пальца, а вот для MxxRu пришлось бы делать какую-то обвязку.

    > Оффтопик - вы ведь переехали в git? Бранчи в духе git flow используете? Или что-то ближе к trunk а-ля svn?

    Так мы и в svn вариант с trunk-ом не особо использовали. Если я правильно помню, у нас и в svn были ветки вроде so-4.3, so-4.4 и so-4.5, от которых уже делались отдельные feature branches, которые затем вливались в нужную ветку. И в tags были папки для so-4.3, so-4.4, so-4.5 и т.д., внутри которых уже фиксировались конкретные версии. Т.е. что-то типа tags/so-4.3/so-4.3.0, tags/so-4.3/so-4.3.0.1 и т.д.

    В git у нас есть master, который содержит самую свежую зарелизенную версию. Например, сейчас master равен тегу v.5.8.1 для SObjectizer-а. При этом есть отдельные ветки для "бранчей" 5.6-dev, 5.7-dev, 5.8-dev.

    Когда начинаем работу над новой версией, то отпочковываем ветку из нужного "бранча". Например, для v.5.8.1 была сделана ветка 5.8-dev-5.8.1. А уже из нее отдельные feature branch-и, вроде 5.8-dev-5.8.1-issue-71 и т.п.

    Когда конкретная фича готова, она вливается в 5.8-dev-5.8.1.
    Когда версия 5.8.1 готова, она вливается в 5.8-dev.
    Если это самая свежая версия, то она вливается в master и уже от мастера фиксируется тег.

    Правда, нам пока еще ни разу не приходилось возвращаться к предыдущим "бранчам". Например, если бы сейчас нас попросили пофиксить что-то в бранче 5.7, то, вероятно, это было бы так:

    - мы бы сделали ветку 5.7-dev-5.7.6
    - от нее уже ветку 5.7-dev-5.7.6-issue-N
    - затем влили бы 5.7-dev-5.7.6-issue-N в 5.7-dev-5.7.6
    - затем бы влили 5.7-dev-5.7.6 в 5.7-dev

    И уже из 5.7-dev фиксировали бы тег v.5.7.6.

    > В чём-то увидели преимущества git как нового инструмента?

    Один или два раза довелось использовать stash :)

    Главное впечатление осталось таким же, как и раньше: это инструмент, мощность и сложность которого многократно превышает мои собственные потребности. Хотелось бы чего-то попроще, вроде того же Mercurial (хотя, признаю, с branch-ами в git все как-то более очевидно, чем в hg).

    При этом я стараюсь часто коммитить и заливать коммиты на сервер почаще. Но это тупо перестраховка на почве боязни потерять результаты работы из-за выхода компьютера из строя. Так что в этом плане для меня больших преимуществ у git перед svn нет.

    ОтветитьУдалить
  5. Тут сразу же вспоминаются цитаты

    «На языках, считающихся ужасными, разработано больше полезных систем, чем на языках, которые хвалят за их красоту, гораздо больше», — Бьёрн Страуструп

    «Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется», — Бьёрн Страуструп

    Если cmake изначально и давным-давно сделан сообществом, то его качество -- это закономерный результат свободы и открытости. Это наследство стародавних времён, когда не всем приходило в голову про модульность и единый репозиторий библиотек.

    Кстати, не знаю, как давно cmake был куплен (или изначально разрабатывался) коммерческой конторой. Если они купили права на доработку открытого ПО довольно недавно, то представляю какой объём "legacy" кода им достался, и неизвестно какими силами они его дорабатывают. Честь и хвала владельцам компании за удачную инвестицию, поскольку (как видно из примера) приличные деньги им ещё долго это приобретение будет приносить. Ну, а их работникам можно пожелать только сил и терпения, и достойной оплаты...

    ОтветитьУдалить
  6. @афмщкфке

    Насколько я помню, CMake -- это детище одной конторы, Kitware, которая создала его в начале 2000-х и пилит до сих пор.

    В то время у CMake был целый ряд альтернатив. Некоторые, имхо, более вменяемые, тот же SCons.

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

    ОтветитьУдалить