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

И зачем тогда в неё влезать?

Чтобы пользователям было удобнее.

Ну так собирай везде ниньзей и будет одинаково.

Мне кажется логичным, что если я описываю свой проект в CMake, то только CMake мне и должно быть достаточно. Если же кроме CMake нужно еще и какую-нибудь ниндзю (или еще что-то) ставить дополнительно, то возникает вопрос: а какой толк в CMake объемом в десятки мегабайт, угребищным синтаксисом и корявой документацией?

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

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

Чтобы пользователям было удобнее.

Так а в чём повышение удобства-то? В том, что ключ -G Ninja не надо вводить?

то только CMake мне и должно быть достаточно

Ну вообще это та самая философия unix. Cmake делает своё дело, ninja/make/… своё. Зависимости есть у многих проектов и почему для cmake они недопустимы мне не очевидно. Я как-то проблемы в этом не вижу.

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

а какой толк в CMake объемом в десятки мегабайт, угребищным синтаксисом и корявой документацией?

Да толк всё тот же, что и был - собирать код. Из адекватных альтернатив cmake’у мне известен только meson, но он так же вызывает ниньзю.

а ты все еще генеришь make-файлы вместо того, чтобы таки заняться build-процессом, то вот это непонятно.

Мэйкфайлы и прочее они, скорее всего, ещё долго будут генерировать для обратной совместимости, что на мой взгляд правильно.

Так а в чём повышение удобства-то? В том, что ключ -G Ninja не надо вводить?

В том, что вообще не нужно париться о стадиях (configure, build). И что не нужно разбираться с тем, что при одном инструменте на выходе получается одно, а при другом – другое.

Мэйкфайлы и прочее они, скорее всего, ещё долго будут генерировать для обратной совместимости, что на мой взгляд правильно.

Где здесь обратная совместимость, если мы все равно проект описываем в CMake. Я бы понял, если бы CMake на вход мог Makefile принимать, так ведь нет.

Нет, найти не удалось.

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

Из адекватных альтернатив cmake’у мне известен только meson, но он так же вызывает ниньзю.

Есть xmake, не знаю насколько оно адекватное – я к нему только присматриваюсь. Умеет само в сборку и если верить их бенчмарку, то по скорости xmake +- одинаков с ninja.

Так а оно есть под linux/mac что ли?

В том, что вообще не нужно париться о стадиях (configure, build).

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

Где здесь обратная совместимость, если мы все равно проект описываем в CMake.

Я имел ввиду использование cmake во всяких ide и тому подобных вещах, а не непосредственно в сборке. Наверное обратная совместимость для этого не самый подходящий термин.

Но скорее всего тут ты прав, сейчас большинство работает с cmake через server mode, или через пресеты, так что это уже не особо актуально и можно и дропнуть при большом желании.

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

Исходники без проблем компилируются например в gcc (внешних зависимостей).

Иногда используется API специфичной ОС, но в целом параметры функций API едины для любой ОС.

Разработка кроссплатформенного кода не мой «велосипед».
Использую «напрокат» тот, который уже создан.

Ещё раз о том, почему использую Visual Studio - «и хрустит и очень вкусно»

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

Видимо потому что меньше зависимостей (нет python, pkgconfig) и он умеет использовать нативные Windows технологии (nmake, VS проекты).

Без проблем в linux? Ты так делал? А в mac?

А свои прлекты там у тебя в формате для VS (.sln, .vsproj и т.д.)? Можно ли собрать такой код из консоли?

Да.

Дружище, посмотри core harbour или SDL.
harbour малого того, что для любой ОС можно собрать, так даже для MSDOS.

свои прлекты там у тебя в формате для VS (.sln, .vsproj и т.д.)? Можно ли собрать такой код из консоли?

Проекты просты, так как не используют сторонний API, кроме стандартного API ОС.
Поэтому non problem создать проект для любой ОС.

Эх, работы ещё «сто вагонов», хотя кое-что уже весьма радует (особенно использование метаданных).

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

Поправочка: 95%.

Пока остальные поделки не научаться устанавливать

ТСЯ.

https://github.com/harbour/core

Makefile
dos-make.exe
os2-make.exe
win-make.exe

Это твоя кроссплатформенная сборка? Какие-то бинари запускать? :-) Рукалицо!!! Для Mac ничего нет. Как это в Visual Studio открыть-то?

https://github.com/libsdl-org/SDL

CMakeLists.txt

Мда.

Проекты просты, так как не используют сторонний API, кроме стандартного API ОС. Поэтому non problem создать проект для любой ОС.

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

Всё там есть (читайте мануалы по сборке).

http://wiki.libsdl.org/SDL2/Installation

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

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

Ныне их нет.
Сделаю, когда закончу разработку кроссплатформенного GUI.

Всё там есть (читайте мануалы по сборке).

Отлично, в мануалах написано используйте CMake:

git clone https://github.com/libsdl-org/SDL
cd SDL
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release --parallel

Как это в Visual Studio открыть-то?

Не разбирался.
Для Visual Studio сделал свой sln и vcxproj и non problem.

Каждый раз в голосину с этой недоразвитой и ублюдочной CMake-лапши:

# SDL_spinlock.c Needs to be compiled in ARM mode.
# There seems to be no better way currently to set the ARM mode.
# see: https://issuetracker.google.com/issues/62264618
# Another option would be to set ARM mode to all compiled files
cmake_push_check_state()
string(APPEND CMAKE_REQUIRED_FLAGS " -Werror=unused-command-line-argument")
check_c_compiler_flag(-marm HAVE_ARM_MODE)
cmake_pop_check_state()
if(HAVE_ARM_MODE)
  set_property(SOURCE "${SDL3_SOURCE_DIR}/src/atomic/SDL_spinlock.c" APPEND_STRING PROPERTY COMPILE_FLAGS " -marm")
  set_source_files_properties(src/atomic/SDL_spinlock.c PROPERTIES SKIP_PRECOMPILE_HEADERS 1)
endif()

• https://github.com/libsdl-org/SDL/blob/2a9480c81581bb81cb265844d54e7ee16a69c4ec/CMakeLists.txt#L1203-L1214
• https://issuetracker.google.com/issues/62264618

Диды разработки Android NDK сделали Makefile Engine (ndk-build) на стероидах, который органично и корректно обрабатывает такие моменты суффиксами – foo.c, foo.c.arm, foo.c.arm.neon и всё! Потом пришли смуззихлебатели с внедрением убогой поделки от KitWare и началось костыление: так как CMake не позволяет нормально отредактировать флаги компиляции для определённого файла, мы просто посрём в comand-line взаимоисключающими -mthumb и -marm, ну а чо, компилятор сам разберётся! Завяжемся на поведение которое в будущем могут поменять и всё сломается к чертям.

https://memepedia.ru/wp-content/uploads/2020/09/9ce2d3974b3dd6ca57cf9491b23c9949.jpg

Зато теперь сборка вместо устаревшего, простого и удобного ndk-build на бибикающем гироскутере CMake!

Чувак, ты говоришь про то, в чём вообще не разбираешься, как и «ядро завязано на расширения GNU C, какой ужас!».

мы просто посрём в comand-line взаимоисключающими -mthumb и -marm, ну а чо, компилятор сам разберётся! Завяжемся на поведение которое в будущем могут поменять и всё сломается к чертям.

Это документированное поведение, оно не может поменяться. То же самое с разными уровнями -O.

https://man7.org/linux/man-pages/man1/gcc.1.html

      The permissible values for feature are listed in the sub-
      section on aarch64-feature-modifiers,,-march and -mcpu
      Feature Modifiers.  Where conflicting feature modifiers are
      specified, the right-most feature is used.

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

Да-да, прямо как не поменялся -fcommon: Кто поломал gcc и главное зачем?

И да, в мире существует не только GCC компилятор. Говнокодить и хардкодить всё под тройку популярных компиляторов, это как раз путь говнокодеров из KitWare создавших CMake или укурков, создавших X.Org для которого до сих пор существуют постыдные пакеты xorg-server-bug865 в репах.

ядро завязано на расширения GNU C, какой ужас!

Всё верно, если бы Linux писали с упором на стандарт C сразу и не пользовались васянскими свистопердячими GCC расширениями – у Linux сегодня был бы не только бОльший охват самых разных устройств (вспоминаем сколько человекочасов потратитил Google выкорчёвывая гнутый C из Linux, чтобы собирать его для Android с помощью Clang/LLVM), но ещё ядро Linux было бы более качественно оттестировано. Потому что код тогда бы сразу тестировался на компиляторах всех мастей – от GCC до ICC, что хорошо бы не только вычистило многие подозрительные места, но и сделало быстрее и производительнее как само ядро Linux, так и порождаемый компиляторами код.

сделал свой sln и vcxproj и non problem

Мдяяяяя. Вот в этом то и суть: сделать проект sln на основе дерева исходников - это еще та задача.

Для SDL и Harbour это не сложно сделать.

Вот когда для сборки требуются запуски каких-то генераторов кода,
скриптов, ... да ещё в определённой последовательности, тогда
действительно сложно, из-за того, что нужно понять «как разработчики до такой жизни докатились».

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

Совершенно НЕ уверен, что в 2023 CMake, лучше SCons.

https://www.reddit.com/r/embedded/comments/q8foqe/scons_vs_cmake/

Пишут, что SCons тормознутый.

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

Но много ли у среднего кустаря, даже с мотором, проектов на тысячи и десятки тысяч cpp файлов?

А на меньших объёмах торможения не добиться.

Так блин, хочется же работать так, чтобы опыт потом пригодился в другом месте…

Так блин, хочется же работать так, чтобы опыт потом пригодился в другом месте…

Мифический опыт… знание конкретного инструмента, один чёрт, вколачивается на раб месте. Те более, что инструментарий меняется и устаревает со скоростью просто неприличной.

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

Опыт не мгновенно нарабатывается. Иначе бы не писали в вакансиях «от 3х лет опыта…».

главное, чтобы опыт не превратился в косность.