CMake 3.28

Очередной слышавший звон, но абсолютно не понявший его сути. Я уже перестал удивляться.

А там ниже писал, что могу ошибаться. :-)

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

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

Ну то есть фактически вы сидите на одной платформе, с минимум зависимостей, разрабатываете в одном ИДЕ, на одной ОС, поддержка всего остального у вас маргинальная. Вы можете вполне прожить без симейка, пока не захотите чего-то большего.

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

А в том же Qt они точно есть? Прямо таки на все аргументы?

Ну давай сравним нормальные доки с доками курильщика, чо. Вот например QString:

https://doc.qt.io/qt-6/qstring.html

Все отлично читается. Куча методов снабжена примерами использования на С++. Назначение параметров либо интуитивно понятно по названию, либо описано ниже в документации.

А вот например документация на find_package в CMake:

https://cmake.org/cmake/help/latest/command/find_package.html#full-signature

Как нормальному человеку читать этот хреново структурированный высер дегенератов из Kitware, написанный отборным канцеляритом? Как быстро понять, какой параметр за что отвечает без текстового поиска по странице? Где хоть один пример использования find_package в CMake коде?

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

Так и Qt также же. И много с чем еще. Основы нужно в книгах статьях учить.

Так-то оно так, только любой С++/Qt разраб тебе скажет, что культи после изучения основ в целом интуитивно понятны и код можно шлепать автодополнением, почти не читая документацию. А вот с CMake у многих так почему-то не получается. Приходится гуглить на каждый чих и лазить по интернет помойкам в поисках FindXXX.cmake скриптов.

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Вспомнил про https://build2.org и их https://cppget.org.

Ага, помню такое. Но эти ребята совсем упоролись и решили самостоятельно переписать сборку существующих С/C++ либ на свой собственный DSL. В отличие от рецептов Conan и vcpkg, которые просто дергают уже существующую систему сборки (CMake, autotools етц), в build2 походу берут сорцы, выковыривают из них оригинальную систему сборки и пишут свои скрипты с нуля. На мой взгляд, это путь в никуда. Они не смогут угнаться за авторами крестолиб и нормально поддерживать самописные скрипты. Они даже культи полностью не смогли портировать. У них в репозиториях есть только модули Qt Core, Qt Gui и Qt Widgets.

Короче говоря если все же охота сварганить из говна и палок унылое подобие Cargo, то на данный момент это будет что-то вроде CMake, примотанного соплями к Conan или vcpkg. Правда судя по опросу жыдбрейнс большинство крестовиков по-прежнему не в курсе про Conan/vcpkg и продолжают пихать сорцы сторонних библиотек себе в репозитории.

Вы можете вполне прожить без симейка, пока не захотите чего-то большего.

Бинго! Это может порвать шаблоны фанатов CMake, но бывают проекты, где кроссплатформенная разработка - есть, CI/CD пайплайн - есть, а вот самого CMake - нет.

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

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

По документации и синтаксису в принципе согласен, могло бы быть получше.

Но только вот этого

стандартную либу для написания сборочных скриптов на крестах

не надо.

Как не нужен и симейк «для крестов». Система сборки должна быть универсальной.

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

И конечно же, использовать с++ для этой цели это ужасная идея. С++ слишком сложен и требует компилятора, линковщика и т.п.

Вот если бы ты говорил о каком-то подмножестве с++ и интерпретаторе с++ встроенном в сборочную систему, тогда ладно.

Я говорю, что есть множество кейсов, где без него прекрасно можно обойтись.

Ну это другое, с этим вроде бы никто не спорит. Без с++ тоже можно вполне обойтись, есть множество кейсов.

Короче говоря если все же охота сварганить из говна и палок унылое подобие Cargo, то на данный момент это будет что-то вроде CMake, примотанного соплями к Conan или vcpkg. Правда судя по опросу жыдбрейнс большинство крестовиков по-прежнему не в курсе про Conan/vcpkg и продолжают пихать сорцы сторонних библиотек себе в репозитории.

Это правда, я сам про конан не так давно узнал. Но сам факт того что пакетирование для С++ написано на питоне… напрягает если честно.

К тому же его до сих пор нет в Дебиане, а это плохой знак.

Вот например QString

Ага, молодец. Посмотри, как классы Qt 3D «подробно описаны».

https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html

де хоть один пример использования find_package в CMake коде?

Хотя бы тут https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html

С++/Qt разраб тебе скажет, что культи после изучения основ в целом интуитивно понятны и код можно шлепать автодополнением, почти не читая документацию

Вот я, как C++/Qt разраб, тебе говорю, что если ты будешь шлепать автодополнением почти не читая доки, то будешь получать на выходе только хелоуворлды.

А вот с CMake у многих так почему-то не получается. Приходится гуглить на каждый чих и лазить по интернет помойкам в поисках FindXXX.cmake скриптов

Ну на каждый чих гуглить нужно, если плохо разобрался в cmake, тут не поспоришь. Вот, что у тебя не получаось?

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Вот есть отличная книга Дубров Денис Владимирович Система построения проектов cmake. Не очень новая, но много пробелов закрывает. После нее уже достаточно доков.

Давай так, я признаю недостатки cmake (как минимум отсутствие типов), и доки Qt конечно лучше. Но Вместе с тем доки cmake вполне норм. Бывает гораздо хуже.

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Гугл спроси, там хоршие ответы

Вот первая же ссылка, например

Там как раз раскрыто, что плохо, что хорошо, лучшие практики и современный симейк и легаси.

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

«На безрыбье и рак рыба».

Не понял, что тебе не нравится?

Да, кстати, чо там у CMake с книгами и статьями?

https://github.com/onqtam/awesome-cmake

хреново структурированный высер дегенератов из Kitware

Лорчую. Ни разу не получилось разобраться в проблеме используя документацию симейка. Не понятно зачем это говно составляется.

В треде не было постов о системах сборки, которые просты и удобны.

Один пост в треде (не мой) был о том, что должна быть разработана удобная система сборки, которая заменит все системы сборки (make, cmake, ...).

Такой tools вполне реально разработать.

Такой tools вполне реально разработать.

Вполне реально, и будут потом опять все такие: «Ой какая херня, выбросить. Должна быть разработана удобная система сборки, которая заменит все системы сборки …».

Такой tools вполне реально разработать.

как_множатся_стандарты.жпег

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

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

Такой tools вполне реально разработать.

Да, и обязательно с зависимостью от libclang, чтобы был интерпретатор C++ JIT. :)

Можно попробовать на форуме сформулировать требования к архитектуре такой системы.

Ага, молодец. Посмотри, как классы Qt 3D «подробно описаны».

Документация на Qt 3D конечно кал, как и сам модуль. Но есть нюанс. QString (и модуль Qt Core вообще) использует любой C++/Qt разраб, а Qt 3D - почти никто. В репозиториях арча нашел только два приложения, использующих Qt 3D: meshroom и qgis. Так что плохие доки на Qt 3D вряд ли кого-нибудь сильно расстроят, а вот плохие доки на find_package - примерно всех.

У меня было бы сильно меньше претензий к докам CMake, если бы основные концепции и команды были подробно разжеваны не хуже, чем Qt Core. Ну а редко используемые команды остались бы как есть.

Вот есть отличная книга Дубров Денис Владимирович Система построения проектов cmake.

Ожидал, что будет корявый машинный перевод доков CMake, но на удивление все довольно неплохо для 2015 года. Жирный плюс за главу с примерами использования OpenCV, Boost, Qt.

Давай так, я признаю недостатки cmake (как минимум отсутствие типов), и доки Qt конечно лучше. Но Вместе с тем доки cmake вполне норм. Бывает гораздо хуже

Ну здесь полностью согласен, не поспоришь. Бывает вообще отсутствие документации :)

Система сборки должна быть универсальной.

Спорно. Идея-то хорошая, но на практике это особо не работает. Вокруг каждого языка образуется свое сообщество, которое пилит тулинг именно на этом языке. Так проще писать и контрибутить в этот тулинг. Если ты посмотришь на какой-нибудь JavaScript/TypeScript, то основные инструменты типа npm, ESLint, Prettier, WebPack, Vite и т.д. написаны на том же самом JavaScript/TypeScript. Равно как и у крестовиков стандартом де-факто стал именно CMake на С++, а не скажем Gradle или даже Meson, хотя последние отлично могут собирать крестопроекты. Поэтому если ты напишешь супер-пупер универсальную систему сборки на крестах, то никто кроме крестовиков ей пользоваться скорее всего не будет.

Вот если бы ты говорил о каком-то подмножестве с++ и интерпретаторе с++ встроенном в сборочную систему, тогда ладно.

Есть такой интерпретатор! Cling называется. Самый настоящий интерпретатор с REPL, который может запускать C++ скрипты без функции main. На днях как раз релиз 1.0 вышел.

Насчет подмножества С++ не скажу, но крестовикам вряд ли понравится искусственно урезанный С++. Вместо этого сборочная система может предоставлять либу для удобного написания сборочных скриптов.

Спорно. Идея-то хорошая, но на практике это особо не работает.

make же в своё время взлетел и стал стандартом отрасли на многие десятилетия и до сих пор используется.

инструменты типа npm, ESLint, Prettier, WebPack, Vite и т.д. написаны на том же самом JavaScript/TypeScript

Я конечно в жабаскрипте не разбираюьсь, но при чём тут система сборки? Эти всё инструменты не для сборки. Ну и зачем приводить в пример скриптовый язык. Понятно что система сборки нужна в первую очередь для языков компилируемых/транслируемых. Фортран, Паскаль, Раст и т.п.

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

Тулинг пусть пишут на чём угодно, мы говорим про систему сборки. Язык, конечно, должен быть достаточно популярным и должен позволять бутстрапиться без проблем и сложных зависимостей на любой платформе, как мейк или симейк. То есть с/с++ это логичный выбор.

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

Насчет подмножества С++ не скажу, но крестовикам вряд ли понравится искусственно урезанный С++.

Глядя на С++ код, очень редко встречаешь что-то читабельное. А ты предлагаешь это всё притащить в сборочную систему, да ещё в нагрузку со всеми UB, сегфолтами, мемориликами, трёхэтажными ошибками темплейтов, зацикливаниями и всеми остальным прелестями С++. Этого всего в сборочной системе быть не должно, а значит чистый С++ не подходит. Плюс не забывай, сборочная система в проекте это зачастую то, о чём заботятся меньше всего, по остаточному принципу. То есть качество кода там будет ниже, чем в основном проекте.

В качестве языка для расширения сборочной системы, для нестандартных каких-то дополнений, для плагинов - да, конечно. Если сделать расширяемый API для вызова своих дополнений при необходимости, то это будет возможно как на С++, так и на любом другом компилируемом языке. Но как основной язык, я против, это будет по-моему и слишком многословно и не очень читабельно и влечёт за собой кучу других проблем, связанных с самим С++.

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

Возможно, кому-нибудь пригодится: https://github.com/quelsolaar/makemake

MakeMake is a tool for generateing and running make files from C code. It does so by parsing the .c and .h files in the same directory as a starting file (usualy the C file containging main), and determains recursivly what files are required to build the project. make make does this by looking for any function declaration using extern, and the searches for the corresponding function definition.

Вспомнил! https://ru.wikipedia.org/wiki/Макемаке 👨‍🚀

Нет, не предлагает. Библиотеки по системным или захардкоженным путям добавляют через target_link_libraries.

Мне так кажется, вы предлагаете лечить заикание вырыванием языка:

То есть с/с++ это логичный выбор.

Глядя на С++ код, очень редко встречаешь что-то читабельное.

а значит чистый С++ не подходит

влечёт за собой кучу других проблем, связанных с самим С++