А в чём профит CMake перед make в главном?

Не кросс-платформа

Cmake умеет работать на windows без установки кучи Unix утилит.

Cmake из коробки умеет работать не только с GCC/clang, но и с msvc.

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

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

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

Во вторых можно с тем же MXE собрать билды под винду прямо с линукса и они довольно стабильные. Подчас намного стабильнее нежели билды собранные с теми же зависимостями от Vcpkg.

автотулзами тоже можно под винду собирать

Попробуй напиши на Make билдсистему для проекта средней величины (aka не «полтора исходника»), которая будет уметь в кросскомпиляцию, опциональные фичи и не будет хардкодить префикс и пути до зависимостей. Потом возвращайся и сам расскажи, чем CMake лучше Make :)

и не будет хардкодить префикс и пути до зависимостей

это всё можно в командной строке make-у передавать

CMake генерирует не только Makefile'ы.

Он ещё может генерировать проекты для разных IDE, например, для MSVC, KDevelop и др.

Кроме того может в Ninja.

Идея здравая, а реализация CMake говно ещё то.

Можно написать Make-файл, который всё делает правильно и настраивается переменными, не вопрос. Примерно как и всё можно написать на языке ассемблера, но жизнь коротка.

Ну, как минимум ninja.

CMake скрывает «всё что под капотом». Поэтому тем кто знает что там - это удобно. Для прочих это тупик.

минус CMake - как минимум необходимость самого cmake, со всеми его зависимостями :-) Меня например это напрягает.. обычный make, sh, text/bin/unix-utils есть везде.

минус Makefile - для больших проектов это ЖОПА. Но у больших проектов она покругу и можно не обращать внимания :-)

А в чём профит CMake перед make в главном?

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

cmake это фултайм работа писать скрипты сборки, это когда один раб кодит, другой раб сидит на сервере и пишет скрипты сборки

кому надо и кодить и собирать одновременно не пользуются cmake

написать 2/3/4/5/6/7/8/9/10 make файлов под каждый компилятор/ОС/версии либы в 100% случаев быстрее чем написание одного cmake конфига

У меня настройка сборки под винду проекта на CMake ограничевается подсовыванием нужного готового тулчейн-файла из Vcpkg / MXE. Автотулзами так можно?

cmake это фултайм работа писать скрипты сборки, это когда один раб кодит, другой раб сидит на сервере и пишет скрипты сборки

кому надо и кодить и собирать одновременно не пользуются cmake

написать 2/3/4/5/6/7/8/9/10 make файлов под каждый компилятор/ОС/версии либы в 100% случаев быстрее чем написание одного cmake конфига

Лол. Баттхёрт неосилятора.

а зависимости у этого твоего проекта есть?

У основного это какбэ Boost, FFMpeg, Qt, SDL2. Ну и есть пара тулзов для клиентов которые я тоже с линукса на винду собираю, но там только Qt.

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

когда сможешь сконфигурировать три разных cmake коспилятора, и три разных gcc компилятора одновременно в одном cmake конфиге, тогда напишешь (каждый компилятора под разную архитектуру процессора)

А что, для тебя это сложно?

У основного это какбэ Boost, FFMpeg, Qt, SDL2.

а пакеты для обнаружения этого всего добра сам писал или брал готовые?

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

я говорю что «создать конфиг cmake» дольше чем make на твой маленький проект, и приводить монстры в качестве примера «успеха симейка» где сотня рабов одни конфиги cmake правит-это глупо

то что это промышленный стандарт это очевидно

А что, для тебя это сложно?

написать 1(одну) строку gcc <опции> для трех платформ и собрать один/два/несколько раз в год

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

у меня на написание проекта на 100-200строк кода на Си уходит меньше времени чем на конфиг cmake файла под этот проект

а пакеты для обнаружения этого всего добра сам писал или брал готовые?

Ну для Boost и Qt скрипты есть внутри самого CMake, а для SDL2 и ffmpeg было видимо еще до меня стырено из других проектов. Работает надо сказать замечательно.

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

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

а для SDL2 и ffmpeg было видимо еще до меня стырено из других проектов. Работает надо сказать замечательно.

т.е. ты не сам с этим пердолился с нуля, а пришёл на готовенькое, понятненько

Ну я лично если не написал, то перебрал ручками вообще весь наш небольшой CMake конфиг. Ну а что до поиска зависимостей - то какая разница насколько там много черной магии если для 99.9% библиотек есть готовые конфиги?

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

-DCMAKE_TOOLCHAIN_FILE=Z:/vcpkg/scripts/buildsystems/vcpkg.cmake

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

я говорю что «создать конфиг cmake» дольше чем make на твой маленький проект, и приводить монстры в качестве примера «успеха симейка» где сотня рабов одни конфиги cmake правит-это глупо

Ты бы хоть читал на что отвечаешь, Vcpkg это тулчейн, а не пример проекта. Мои маленькие хеллоуворды на Qt для клиентов все равно надо собирать на венды и маки. Спасибо CMake я могу их собрать в виде dmg / инсталлера одной командой.

Если тебе приходится работать в области где надо собирать на 10 разных архитектур с удобствами на улице и где нет готовых инструментов, то мне тебя жаль. Но это не значит что CMake не экономит время всем остальным.

тыб еще джаваскрипт кодинг в браузере за успех привел...ох вейт

как там скриптики и CSS на КуТэписать? Симейк сильно помогает?

в голосину чето

Еще есть такой минус makefile как совместимость между имплементациями. GNU Make довольно фичаст, но традиционный make (например на солярке) — просто убожество. В CMake ты просто пишешь и имеешь спокойствие

cmake_minimum_required(VERSION 3.6)

К СMake также довольно просто прикрутить сборку пакетов (deb, rpm, nsis,...). С Make тоже не сильно сложно, но нужно все ручками. Но отсюда и проблема: местами в CMake просто нет нужных средств, чтоб задать специфическую опцию для генератора пакетов. Например до некой версии не можно было на выхлопе получить файл пакета (deb/rpm) со стандартным именем (CPack переименовывал по своему). Сейчас пофикшено и неактуально.

CMake предоставляет более способ конфигурации, в Make нужно велосипедить.

В общем все плюсы CMake вытекают из куда более развитой функциональности и «стандартной» библиотеки и подключаемых модулей. В Make же, писатель начинает с минимумом, что конечно имеет свои плюсы и заманчиво с точки зрения «покопаться». Но ведь лучше писать код чем скрипты сборки, так?

я говорю что «создать конфиг cmake» дольше чем make на твой маленький проект, и приводить монстры в качестве примера «успеха симейка» где сотня рабов одни конфиги cmake правит-это глупо

Минимальный скрипт CMake очень простой:

project(HelloWorld)
add_executable(${CMAKE_PROJECT_NAME} main.cpp) 

Причем сразу же будет цель clean и прочие плюшки CMake как например возможность задать тулчейн извне.

Минимальный скрипт CMake очень простой:

а добавить к этому десяток либ которые тоже компилятся под архитектуру(по конфигу смейка на каждую сам делать будешь)

когда в make все ограничивается копипастой путей/опций компиляции

хотя мне и функционал make не всегда нужен, почти всегда достаточно .sh скрипта на 2 строки

а для SDL2 и ffmpeg было видимо еще до меня стырено из других проектов. Работает надо сказать замечательно.

Первая ублюдочность CMake, которую правильно подметил Harald. На одни библиотеки мы FindModules положим, на другие — хер положим.

Оценки хелловорлда тред (комментарий)

Не зря RedHat пытается мигрировать на Meson с этого угрёбища.

DCMAKE_TOOLCHAIN_FILE=Z:/vcpkg/scripts/buildsystems/vcpkg.cmake
И оно собралось под виндой и работает. С автотулзами так можно?

Для autotools'ов в идеале тебе вообще никаких файлов писать не нужно, а просто задать host/build/target и переменные окружения. Вот только слабая поддержка autotools'ами винды и UNIX-наркомания ставит на поддержке этой OS жирный крест.

Ни в чем. Лишняя фигня, затрудняющая работу. Так-то в составе MS-овских средств разработки есть своя версия Make - NMake. Она, конечно, не такая фичастая, как GNU Make и даже BSD Make, но если немного покурить маны, то написать кроссплатформенный Makefile особой проблемы не составит.

Первая ублюдочность CMake, которую правильно подметил Harald. На одни библиотеки мы FindModules положим, на другие — хер положим.

Ну с этим я совершенно не спорю - лазить по помойкам за find модулями не самое приятное занятие, но ничего лучше CMake пока не появилось.

Не зря RedHat пытается мигрировать на Meson с этого угрёбища.

И конечно же редхат будет поддерживать все платформы которые поддерживает CMake (нет)...

CMake даёт возможность с меньшими затратами труда написать одну систему сборки, которая потом будет работать c разными компиляторами и разными целевыми системами. Достаточно просто использовать CMake правильно и использовать (или писать самому) хорошие годные кроссплатформенные библиотеки Find<Whatever> модули, ну и сам код писать кросплатформенный. Для кроскомпиляции есть toolchain'ы, и вроде народ пользуется и доволен, сам не скажу...

Если проект небольшой и предназначен только для одной платформы и одного компилятора, то Makefile'ы и вправду лучше, наверное.

Хотя есть ещё пара удобств в виде поддержки создания установщиков (но это под оффтоп больше актуально), CTest для автоматизации тестирования и можт ещё что-то, что я забыл уж

Cmake из коробки умеет работать не только с GCC/clang, но и с msvc.

Замечу, что с компиляторами он работает весьма убого (грубо говоря, кроме release/debug/-std=/include_paths ничегошеньки не знает), а с линкерами вообще никак, так что в «не helloworld-ах» очень часто можно встретить ручное задание опций с ветвлением по gcc/clang.

Что понимается под работой с линкерами и компиляторами?

Нет у него особых преимуществ. Ну, может, внутренние зависимости проще отслеживать — само работает. Но эта фича и в других системах сборки есть.

а добавить к этому десяток либ

Конечно конские запросы для «маленького» проекта. А монстры типа Qt, boost уже имеют модули для «find_package» (причем, прошу заметить, find_package работает согласно с настроенным тулчейном).

хотя мне и функционал make не всегда нужен, почти всегда достаточно .sh скрипта на 2 строки

Тут не поспоришь, для ad hoc просто берется любимый «золотой молоток».

Про gradle бы ещё вопрос, в заголовок и первый пост.

gradle vs cmake :)

Что понимается под работой с линкерами и компиляторами?

Ну, к примеру, разрешить avx инструкции (gcc -mavx), или скрыть некоторые символы в результирующем бинарнике, или слинковаться статически с частью библиотек, полученных от pkg-config. cmake весьма убог, если приходится делать что-то отличное от «скомпилировать вон те два файла в бинарник».

gradle vs cmake :)

Кто-то на полном серьезе будет использовать это для сборки не-java приложений?

Я видел плюсные проекты, которые градлом собираются и не только плюсные

Люди вполне используют для C, C++
Ибо даже зависимость от jvm выглядит более адекватно, чем угрёбищность CMake-макросни.

https://github.com/dreamstalker/ReHLDS
https://github.com/theAsmodai/metamod-r

Не очень правильно сравнивать сборщик и систему конфигурации сборки. По идее надо сравнивать с autotools, meson, waf и т.п.

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

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

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

Или - как в make без сторонних (и не портабельных) утилит - получить compilation database?

На самом деле список очень долго можно продолжать.

разрешить avx инструкции
скрыть некоторые символы в результирующем бинарнике

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

слинковаться статически с частью библиотек, полученных от pkg-config

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

find_package(FooBar REQUIRED COMPONENTS static_lib)
target_link_libraries(MyAwsumProgram FooBar::static_lib)

Короче, тоже согласен. Не знаю зачем я всё это сюда принёс :D

Люди вполне используют для C, C++

Люди вообще много странных вещей делают. Сходил по твоим ссылкам, захлебнулся бойлерплейтом.

Но таки какой-то стандартизации в этом плане нет

Самое печальное, что многие поставляемые с cmake find-скрипты не предоставляют imported targets . Собственно, найти какие-то вменяемые cmake best practices в гугле пару лет назад было сложнее, чем наговнякать бяку на коленке, как все и поступали.

Меньше глупой писанины.