CMake наконец-то поддерживает модули во всех компиляторах С++

Насколько я понял gcc в 13-ой версии сам не поддерживал какой-то там протокол для поиска модулей. Т.е. проблема таки не в cmake была, а в компиляторах.

Но новость безусловно хорошая. Осталось только дождаться того, чтобы в cmake из experimental это всё вынесли.

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

да уж выясняли уж, толку то теперь выяснять

после драки кулаками

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

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

осталось только выяснить, чем эти модули лучше PCH.

ox55ff
Тем, что с модулями не нужны костыли типа namespace detail и т.п. Модули дают возможность нормально скрывать реализацию и чётко описывать экспортируемый интерфейс.

А кто-нибудь может пояснить, почему C++-программисты создали CMake вместо нормальной системы сборки? Ведь умные же люди. И как вообще настолько убогий и отвратный проект стал негласным стандартом в мире C/C++ разработки? Прямо родили второй autotools, а ведь альтернатив была огромная масса.

Почему разработчики под Windows его так любят, а разработчики под Linux переводят с него проекты на Meson?

Почему вообще в IT всегда набирают популярность, становятся стандартом и побеждают наиболее идиотские и упоротые решения: PHP, CMake, Bash, X11, Make и др., тогда как адекватно спроектированные решения и их аналоги выкидывают на помойку?

PCH тот ещё костыль.

А кто-нибудь может пояснить, почему C++-программисты создали CMake вместо нормальной системы сборки?

Тут вопрос не в том, почему создали CMake. На самом деле создавали много чего. Я когда собственную систему сборки сделал и пытался ее хоть как-то продвинуть в районе 2005-2006 годов, обнаружил, что подобных систем штук 15, если не больше (разной степени живости, но тем не менее). И это только то, что было известно публично.

Вопрос в том, почему именно CMake взлетела.

Одна из версий в том, что для конфигурирования C++ проекта нужен практически полноценный ЯП, а добавлять поддержку стороннего нормального ЯП (уровня Python или Ruby) в C++ IDE, вероятно, сложнее, чем поддержку CMake.

Почему вообще в IT всегда набирают популярность, становятся стандартом и побеждают наиболее идиотские и упоротые решения: PHP, CMake, Bash, X11, Make и др., тогда как адекватно спроектированные решения и их аналоги выкидывают на помойку?

Вы так говорите, как будто про принцип «worse is better» никогда не слышали.

Есть несколько систем сборки как на Python, так и на Lua, даже на json/qml и ini, вот только по возможностям все до сих пор уступают CMake, либо имеют какие-то свои неприятные особенности реализации.

После того, как CMake стал мейнстримом, пропал смысл вкладываться во все остальное. Удивительно, что Meson все еще пилят.

А лет 10-15 назад CMake вряд ли был принципиально лучше какого-нибудь SCons.

побеждают наиболее идиотские и упоротые решения: PHP, CMake, Bash, X11, Make и др.

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

почему C++-программисты создали CMake вместо нормальной системы сборки?

Потому что kitware захотели сделать кроссплатформенный make. И сделали. Остальное оказалось хуже.

А сейчас у cmake есть по сути только один недостаток - всратый синтаксис (ну и generator expressions не раскрываются на этапе конфигурирования, даже для известных параметров, но это личная боль). Во всём остальном он отлично справляется.

И если единственное преимущество meson’а - это нормальный синтаксис, а во всём остальном он не лучше или хуже, то на кой чёрт кому-то переходить с cmake на него? Про cmake точно известно, что он держит обратную совместимость и не ломается на каждый чих, и известно, что он позволяет делать всё, что нужно для сборки C++-проектов.

Про meson известно только то, что гномеры и компания переходят на него с автотулзов. Но эти люди сидели на автотулзах и им было ок. Они последние, к чьему мнению стоит прислушиваться.

Ну вот и получается, что meson прекрасная никому не нужная система сборки.

Почему разработчики под Windows его так любят

Скорее всего потому что cmake не требует питона и подобных внешних зависимостей. Но тут надо у win-разрабов узнавать.

А какой ещё есть шелл с таким же набором фич, как в баш?

Почему вообще в IT всегда набирают популярность, становятся стандартом и побеждают наиболее идиотские и упоротые решения: PHP, CMake, Bash, X11, Make и др., тогда как адекватно спроектированные решения и их аналоги выкидывают на помойку?

У тебя в начале списка упоротых решений C потерялась.

Скорее всего потому что cmake не требует питона и подобных внешних зависимостей. Но тут надо у win-разрабов узнавать.

Как минимум потому что легко(в одну строчку) из CMakeFiles сгенерировать vsproj и загрузить его уже в студию и в ней отлаживать проект. Возможно с Meson не сложнее, но это я не в курсе. А в QtCreator даже этого не надо, просто открыть проект и всё само сконфигурируется.

Вот написал бы Линус свою терминалку на лиспе - вот житуха бы началась!

Поддержка meson’а в qtcreator’е тоже есть, как минимум если плагин включить. Насчёт vs не знаю.

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

Одна из версий в том, что для конфигурирования C++ проекта нужен практически полноценный ЯП,

А точно нужен ли?

Виндопрограммисты ментально не способны осилить инструменты сложнее кнопочки запуска в IDE. Поэтому я не понимаю о какой популярности CMake именно под Windows идёт речь. Там где проекты написанные чисто под винду, там просто проектник для студии. Там где виндопрограммист пытается понять что такое это ваша кроссплатформа, ему первым в выдаче попадается CMake. Как же удобно что его нативно поддерживает любимая виндопрограммистом студия.

А точно нужен ли?

Я первую свою «кросс-платформенную» систему сборки для C++ных проектов сделал где-то году в 1995-ом или 1996-ом на базе Watcom-овского make (Windows и OS/2 нужны были). Потом затрахался с make, сделал на плюсах свою утилиту с типа декларативными описаниями. Потом затрахался описывать в декларативщине особенности разных платформ с разными компиляторами и линкерами, потребовалось иметь хотя бы if-ы и циклы. Сделал простой императивный С-подобный язык, настолько простой, что там даже подпрограмм не было, все было более чем минималистично. Спустя пару лет убедился, что этого минимализма не хватает. И вместо того, чтобы дорабатывать свой недо-язычок, просто посмотрел на имевшиеся вокруг скриптовые языки и выбрал Ruby. И все еще думаю, что это был правильный выбор, ибо при адаптации к конкретным версиям ОС, компилятора, режимов сборки и библиотек, иногда чуть ли не фазу Луны нужно учитывать (шутка) и когда у тебя под рукой полноценный ЯП, то сделать это можно легко и непринужденно.

В принципе, если посмотреть на более-менее продвинутые и нормальные CMake-скрипты, то в этом можно самостоятельно убедится.

Хотя, конечно, придумать настолько угребищный синтаксис как в CMake… Это нужно постараться было.

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

Ну открой любой хедер, в котором есть namespace detail, impl и подобные и посмотри, что они не смогли оттуда вынести в cpp. Как правило это шаблоны и тому подобное. Всё это детали реализации и всё это держится только на негласном соглашении, что пользователи не должны ничего дёргать из таких неймспейсов.

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

Одна из версий в том, что для конфигурирования C++ проекта нужен практически полноценный ЯП

Любой достаточно развитый конфиг эволюционирует в сторону ЯП (изначально как DSL). Даже в декларативных по определению верстально-разметочных «не-ЯП» внезапно появляются циклы, ветвления и/или биндинги к более-другой скриптоте :)

Теперь у всех цмаке сборки поломаются, так как разрабы будут требовать новую версию так что перед сборкой проекта собери цмаке цмайком :D

зачем мне открывать какие-то поделки говнокодеров?

Ну да, ну да. 90% плюсовых библиотек пишутся говнокодерами, один ты знаешь как надо, но никому не расскажешь.

В общем проблема тебе описана. Если ты её не хочешь/не можешь понять, то дело твоё, я не настаиваю.

Почему разработчики под Windows его так любят, а разработчики под Linux переводят с него проекты на Meson?

Толстовато. Я использую симейк и на линупсе по причине КОНФИГУРАЦИИ. Пока остальные поделки не научаться устанавливать дебаг и релиз одновременно - они не нужны.

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

Конечно. Если языка конфигурирования не хватит, то ты просто вызовешь внешний питон как билд степ, потому что тебе «задачи решать», а не сражаться с билдсистемой. И, да, это было с бородатых годов ещё во времена мейка (sed -e ‘kokoko’ и т.д.)

Да камон, это же баш со скобочками. Ублюдочно? Без сомнения. Легко? Без сомнения.

Я тоже подумал, что meson для windows потребует установки питона, но msi поставляется уже с питоном внутри и meson не привязан к системному.

Scons так вообще предлагает бинарные standalone сборки, которые можно с проектом таскать.

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

Открой тогда стандартную библиотеку.

Там достаточно много деталей реализации, которые начинаются с _.

В модулях они не экспортируются практически.

Только _Pipe::operator| был экспортирован из всего что начинается с _, чтобы | оператор для range заработал, так как он ищется по ADL.

И ещё, последние версии meson нельзя установить и использовать из msi на windows 7 (начиная с версии 0.56.2 от 10 января 2021 года), только через pip. То есть нужно сначала установить хотя бы python 3.8.10.

CMake прекрасно продолжает работать.

PCH один на все заголовочные файлы используемые в проекте/библиотеке. Слишком большая гранулярность. А, как известно, в C++ из-за макросов важен порядок инклюдов и куда их инклюдят. А модули компилятся по одному и можно подключать в каждую единицу трансляции только те, что надо.

Нестандартизировано. В каждом компиляторе PCH работает по-своему.

Как минимум в GCC PCH реализованы через жопу, что компилятор падает при включенной рандомизации кучи (потому что в PCH дампятся прямо адреса памяти в процессе компилятора) на определённых конфигурациях.

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

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

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

В итоге мой инклюд засоряет пространство имён того, кто его использует, своими потрохами.

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

У premake были все шансы взлететь - lua, кроссплатформа. Но увы, не взлетел.

сделал на плюсах свою утилиту с типа декларативными описаниями. Потом затрахался описывать в декларативщине особенности разных платформ с разными компиляторами и линкерами, потребовалось иметь хотя бы if-ы и циклы. Сделал простой императивный С-подобный язык

А исходники твоей утилиты с типа декларативными описаниями до появления C-подобного языка сохранились? (И заодно пример файла проекта в твоём синтаксисе.) Меня периодически подмывает пойти по этому же пути, но мешает осознание, что с вероятностью 99,9999999% кончится всё 100500-м заброшенным велосипедом, их в мире сборочных систем и так хватает.

А исходники твоей утилиты с типа декларативными описаниями до появления C-подобного языка сохранились?

Я постараюсь, конечно, поискать вечером в старых архивах. Но сильно сомневаюсь, что найду, дело было где-то в 1997-ом.

Вообще, история оказалась даже более веселой, чем я запомнил :) Промежуточных шагов на пути к Ruby-версии было больше:

• m++ на базе Watcom-овского wmake;
• m++ v2, с декларативными описаниями (не уверен, что его исходники получится найти);
• m++ v3, в котором уже что-то похожее на Си, но сильно урезанное (здесь так же мало шансов найти исходники);
• m++ v4, в котором уже подобия Си было уже сильно больше.

Пример проектного файла на m++ v3 выложил сюда (это проектные файлы для сборки m++ v4 посредством m++ v3).

И заодно пример файла проекта в твоём синтаксисе.

Если речь про декларативный m++ v2, то попробую найти но ничего не обещаю, вряд ли такое сохранилось.

А кто-нибудь может пояснить, почему C++-программисты создали CMake вместо нормальной системы сборки?

Да потому что стандарт не определяет, единую систему сборки. Поэтому и появилось пачка систем сборки.

Заслуга CMake как раз в том, что он объединяет большинство систем сборки по большей части прозрачно. Т.е. используя его можно собирать на чем угодно (ну почти). Ведь cmake - это даже не система сборки, а система управления системой сборки.

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

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

А что в этом крутого?

Ну вот если взять оффтопик. Там можно из CMake сгенерировать «проектные» файлы под NMake, Ninja и VisualStudio. При этом, например, довелось столкнуться с тем, что:

• Ninja можно запустить в параллельную сборку, тогда как NMake нельзя;
• Ninja и NMake оставляют .manifest-файлы (не влинковывают их в .dll/.exe), тогда как VS влинковывает;
• если запускать сборку из командной строки через cmake --build, то Ninja/NMake останавливаются если компилятор находит ошибку в .cpp-файле, тогда как VS продолжат компилировать как ни в чем не бывало, выплевывая сообщения об ошибках о невозможности линковки из-за отсутствия .obj (а его нет, т.к. .cpp-файл не был скомпилирован).

Ну вот смотри. Системы сборки (visual studio, ninja, make, nmake, xcode) будут пилить до тех пор, пока система сборки не станет стандартом.

А вот мне как разоаботчику нужно делать кроссплатформенный проект под win(msvc), linux(gcc), mac(clang из xcode). Что мне делать? - ну можно использовать ninja наверное. Но это низкоуровнево, т.е. много писать придется руками кода для ninja. Кроме того ninja не стандарт, они небольшой проект, вот они завтра загнутся и что делать? Или вот еще: вот допустим часть команды работает в Visual Studio, часть в Xcode, ни первое, ни второе не откроют проект, который оформлен на ninja, что делать?

Как обычно.

Понадобилась мне возможность конвертации шаблонов отчётов FastReport в mxl 1С - взял да и разработал.
Проблема в том, что многие могли бы решить вопрос, но предпочитают ждать халяву.

PS: На самом деле проблема в том, что нет API, которое умело бы работать с метаданными.
У меня есть, поэтому без проблем решил например вопрос конвертации метаданных doc и xlsx в свой формат (конечно программно).
И более того API предоставляет возможность работы с любой секцией метаданных.
А в той же LibreOffice несколько тысяч строк с определениями struct («жалко птичку»).

----------------------------------------------------
Пост был о том, что нужно не лабы писать, а профессионально решать вопросы.

Странный вопрос. Ну реально.

Если вы закладываетесь на CMake, то уже пофигу, что там под ним (vs, xcode или еще какая хрень). Вы видите только CMake.

Ну так и пусть CMake будет полноценной билд-системой, которая запускает компиляторы/линкеры/пр. Чтобы работать одинаково вне зависимости от подложки (vs, xcode или еще какой хрени).

Но нет, почему-то людям нравится, что CMake них*я сама строить не может, может только нагенерить 100500 файлов(1), которые затем какой-то нативной системой сборки должны собираться.

Это еще можно было понять году в 2005-ом, когда каждая IDE понимала только свой формат проектных файлов. И приходилось из метаописания (того же CMakeLists.txt) генерировать какой-нибудь .vcproj, чтобы открыть проект на конкретной платформе в конкретной IDE.

Но теперь же вроде как все напрямую CMakeLists.txt открывают. Так с какого хера CMake все еще нуждается в Ninja и пр?

Несколько лет назад был удивлен тем, что установленный CMake под Windows занимает больше места, чем установленный Ruby. И это при том, что Ruby таки полноценный ЯП с приличного размера стандартной библиотекой. Тогда как CMake как язык вообще редкая срань на фоне Ruby. Ну и на Ruby не так уже и сложно сделать построение make-tree с запуском build-процесса и контролем результата.

А вот «программисты» из Kitware (или кто там выдал эту жертву аборта) почему-то осилить такое в своем CMake нисмагли.

(1) кстати говоря еще один повод оправить криворучкам, создавшим CMake и думающим, что они программисты, порцию лучей поноса.

А, как известно, в C++ из-за макросов важен порядок инклюдов и куда их инклюдят.

Единственное, где я такое видел это windows.h. Везде кроме винды всё работает с произвольным порядком инклюдом, а если не работает, то дело в говнокоде требующем к себе особый подход. В этом случае нужно говнокод переписывать/выкидывать, а не подстраиваться под него.

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

Ну так и пусть CMake будет полноценной билд-системой, которая запускает компиляторы/линкеры/пр.

Так с какого хера CMake все еще нуждается в Ninja и пр?

Тут я согласен. Нечего сказать.

Может быть боятся, что не потянут?

Не знаю нужно ли, но наверное можно конвертнуть метаданные Ninja в формат Visual Studio.

Кстати использую бесплатную Visual Studio 2013.
Профит в том, что в ней 99.9999% процентов программист тратит время на разработку, а не на «разруливание» всяких проблем с билдером, ...
Да и при разработке кроссплатформенного API non problem.

У меня нет ответа, к сожалению.

Ну так и пусть CMake будет полноценной билд-системой, которая запускает компиляторы/линкеры/пр.

А какой смысл велосипедить ниньзю, если она уже существует? Скорее всего они не хотят делать лишнюю работу. По слухам ниньзя при пересборке работает быстрее конкурентов. Да и во множестве ide со своей билд системой была частая болезнь, что если что-то не собирается, то надо почистить проект. Значит организовать нормальную сборку не самая тривиальная задача. И зачем тогда в неё влезать?

Чтобы работать одинаково вне зависимости от подложки (vs, xcode или еще какой хрени).

Ну так собирай везде ниньзей и будет одинаково. Если они сделают свою сборку, интегрированную в cmake это всё равно не будет ничем отличаться от -G Ninja, так в чём проблема просто пользоваться уже существующим?