Cmake что это за программа

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

gcc main.c

а для MSVC вот так:

cl.exe main.c

Однако, любой мало-мальски сложный проект содержит не один, а несколько (много!) файлов с исходным кодом. Можно было бы создать простенький скрипт, в котором было бы написано

gcc file1.c file2.c . file123.c

Однако каждый раз, внося изменения лишь в один из файлов с кодом, вам нужно будет перекомпилировать программу, а эта команда будет пересобирать все 123 файла. Это медленно и неудобно. Требуется нечто, что будет детектировать измененные файлы и пересобирать только их.

make

Одним из таких решений является утилита make . Если вдаваться в подробности, то существует несколько диалектов make : на Linux используется т.н. GNU Make, на FreeBSD — BSD Make, а на винде — NMake.

make принимает на вход файл, описывающий правила. Каждое правило — это просто одна или несколько команд, которые производят какой-либо файл. Правила могут использовать файлы, получившиеся в результате выполнения других правил, и, таким образом, формируется дерево зависимостей. Все конечные результирующие файлы объединяются в правило all , поэтому команда make all позволяет «собрать» весь проект.

Основы CMake

Я взял слово «собрать» в кавычки потому что, на самом деле, make не обязательно используется только с компиляторами. Мануал по make в заголовке гласит:

make – maintain program dependencies

Т.е. make — это программа для управления зависимостями, причем не важно зависимостями чего от чего.

Конфигурация проекта

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

1. Директории, содержащей заголовочные файлы библиотеки.
2. Директории, содержащей саму библиотеку.

Заголовочные файлы указываются флагом -I в Unix-подобных ОС и флагом /I в компиляторе Microsoft:

gcc -I/full/path/to/vasyanlib/include . cl.exe /I»C:Program FilesVasyanLibInclude» .

Аналогично, директории для библиотек указываются с помощью -L / /LIBPATH .

Но вот незадача — на разных компьютерах VasyanLib может быть установлена в разные директории! Это означает, что если вы захотите дать ваш код другому человеку, или просто самому скомпилировать ваш код на другой машине, то вам придется редактировать свой скриптик сборки (читай, команду вызова компилятора).

Это особенно неудобно, если ваш скрипт сборки находится под управлением системы контроля версий ( git , hg , svn и т.д.), ведь вам придется либо каждый раз коммитить эти изменения, либо они будут «висеть» у вас незакомиченными.

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

CMake основы

Таким образом, помимо этапа сборки проекта появляется этап конфигурации. На этом этапе с помощью каких-либо скриптов или программ производятся необходимые проверки и поиски, а результат заносится в Makefile (ну, на сегодняшний день этот Makefile просто генерируется целиком) и/или оформляется в виде заголовочного файла с рядом директив #define , позволяющих в коде определить наличие того или иного файла или фичи.

Системы сборки

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

1. Определяют структуру проекта, т.е. из каких «целей» он состоит. Например, проект может состоять из библиотеки, приложения, использующего эту библиотеку, и набора приложений-тестов.
2. Решают задачу конфигурации проекта.
3. Решают задачу сборки проекта.
4. Решают дополнительные задачи: очистка — удаление результатов сборки, тестирование — запуск тестов определенным образом, упаковка — создание релизных архив и инсталляторов, и т.д.

Пожалуй, первой системой сборки был Autotools. Сейчас их уже тьма-тьмущая и CMake, на мой взгляд, является наиболее универсальной из них. Остальные системы сборки либо зависимы от ОС, либо зависимы от языка программирования.

CMake vs IDE

Вот теперь, рассмотрев всю историю, можно разобрать и вопрос о том, является ли CMake и вообще системы сборки «наследием», и обошли ли их IDE.

Ответ — конечно нет. Подтверждение этому можно найти не только в том, что системы сборки постоянно и активно развиваются, но и в том что даже в Visual Studio, той самой IDE, которой не требовалась никакая система сборки, была добавлена поддержка CMake.

Пара слов о Visual Studio. Эта IDE имела свой формат проектов, и, по сути, свою собственную систему сборки. Проекты студии в функциональном смысле были эквивалентны Makefile ам или CMakeLists.txt ам. Неудобство пользованиями ими, на мой взгляд, заключается в следующем:

1. Отсутствует этап конфигурации. На сегодняшний день мне неизвестно как в С++ проекте студии указать, что ему требуется VasyanLib , да так чтобы при попытке собрать проект, студия бы спросила меня о местонахождении этой библиотеки, вместо того чтобы плеваться ошибками сборки.
2. Сложно использовать сторонние утилиты в процессе сборки. Например, у меня есть проект, который сначала собирает программу на Хаскелле, запускает ее, а она производит код на С++, который уже превращается в конечную программу. На CMake это заняло строчек 10, а на студии мне неизвестно как это реализовать.

Философия

На самом деле, файлы проектов IDE не нужны. Они не нужны по той причине, что файлы CMakeLists.txt — это уже файлы проекта. Причем они универсальны и не привязаны не только к ОС, но и к используемой IDE — в настоящее время CMake умеет генерить ,помимо Makefile, проекты Visual Studio и Eclipse.

Первая IDE, на мой взгляд, которая поняла эту глубокую мысль — KDevelop. В ней файлы проекта отсутствуют в принципе. Это не только классное решение с принципиальной точки зрения, но и имеет практическую ценность — например, KDevelop «видит» файлы проекта точно так же как сам CMake. В частности, если какой-то #include у вас подчеркивается красным, то это означает что вы накосячили в коде CMake. А в студии эта ошибка могла бы пройти мимо глаз, и проявиться только на другом компьютере с другой конфигурацией директорий.

Надеюсь, за такой развернутый пост мне простят беззастенчивую рекламу KDevelop. Но это и вправду замечательная IDE, на разработку которой я потратил немало времени.

Отслеживать
ответ дан 28 ноя 2019 в 18:55
1,612 11 11 серебряных знаков 13 13 бронзовых знаков
то есть это просто продвинутая система сборки я так понимаю.
– user252359
29 ноя 2019 в 13:30

«Сложно использовать сторонние утилиты в процессе сборки.» — в VS довольно давно (а может и всегда) были шаги prebuild и postbuild. Так что хаскельный генератор кода просто прописывается в prebuild и будет запускаться когда надо. Вроде там даже больше триггеров есть.

29 ноя 2019 в 15:29
29 ноя 2019 в 16:25
1 дек 2019 в 7:59
1 дек 2019 в 8:15

CMake (равно как и make, qmake, gmake, consul итд) нужен для описания правил сборки проекта. То есть он призван отвечать на вопросы

• Где у проекта лежат исходники?
• Какое имя бинарника проекта?
• Какие имена библиотек проекта?
• Какие внешние библиотеки проект использует и где они находятся?
• Сборка в дебаг или релиз?
• Какие действия выполнить перед сборкой? А после?
• Что нибудь ещё.

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

При этом файл CMake намного более читабелен и понятен, чем, например, solution в visual studio.

Я, например, в одном из своих pet-проектов про arduino одним CMake-файлом собираю демона для linux, прошивку для arduino и заливаю эту прошивку в arduino.

Отслеживать
ответ дан 28 ноя 2019 в 12:36
3,106 11 11 серебряных знаков 31 31 бронзовый знак

Для организации C/C++ проекта. Достаточно зайти на официальный сайт https://cmake.org/.

CMake is an open-source, cross-platform family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice.

Отслеживать
ответ дан 28 ноя 2019 в 8:24
user361503 user361503
11 1 1 бронзовый знак
То есть утилита бесполезная если я уже знаю какой компилятор я буду использовать?
– user252359
28 ноя 2019 в 8:29
28 ноя 2019 в 9:28

Да, но то есть в IDE у меня получается уже есть и билдер и компилятор.
– user252359
28 ноя 2019 в 9:40
28 ноя 2019 в 13:37

Для создания программ под микроконтроллеры альтернативе утилитам make и cmake иногда просто нету. IDE от производителя вставляют в код большой объем не используемого кода и удалить его из программы средствами IDE не возможно. Приходится собирать проект без IDE.

Отслеживать
ответ дан 3 дек 2019 в 8:26
3,020 1 1 золотой знак 11 11 серебряных знаков 20 20 бронзовых знаков

не надо путать make и CMake. Если грубо, make исполняет MAKEFILE, CMake — создаёт MAKEFILE, чтобы make мог его выполнить. CMake is an open-source, cross-platform family of tools designed to build, test and package software. И про IDE: приведите пример.

6 дек 2019 в 9:58

Утилиты make и Cmake это наследие Unix с тех времен, когда не было IDE, а в качестве терминала была пишущая машинка Консул(!). 🙂 В принципе, Unix-оиды до сих пор тащат эту методологию разработки и построения проектов, как наиболее общую. Иногда без нее не обойтись, но ее доля в реальной жизни снижается. Все работают на IDE и не заморачиваются с make и Cmake.

Вот еще для чего может понадобится Cmake, так это для распространения программ в виде Open Source. Если автор предоставляет Cmake для проекта, то пользователю проще на своей машине перестроить проект. И пользователю не надо в этом случае разбираться где там исходники, где хедеры, где библиотеки и прочее. Если же распространять с проектом не Cmake, а конфигурационный файл для IDE, то во-первых легко перестроить проект получится только с таким же IDE. А во-вторых IDE на машине пользователя должно стоять на том же диске и с теми же путями, что и на машине автора проекта.

то этот пост все равно бы не объяснял — почему?

ТС и не спрашивал «почему». ТС спрашивал «зачем». ТС спрашивал зачем ему да и всем нам нужен CMake, если давно есть удобные IDE. Я попытался ответить зачем сейчас, в 2019 году, может быть нужен CMake. Ничего более убедительного, чем распространение Open Source проектов не вспомнилось.

Ответ же «почему» очевиден — потому что с IDE проще работать. При использовании IDE не надо вручную править конфигурацию CMake каждый раз при добавлении файла исходников в проект. И в IDE все в одном флаконе — и редактор, и отладчик, и компилятор и подсветка синтаксиса и форматирование исходников и подсветка ошибок и профилятор и еще куча всего.

Всего этого нет в CMake и вообще всего этого нет в старой методологии разработки через командную строку. Именно поэтому CMake «загнан в темный угол». Именно поэтому 99% программистов работают только с IDE.

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

Не критично. 99% проектов обходятся статическим указанием на местоположение библиотек. Если будет критично, то эту функцию добавят в IDE.

Сложно использовать сторонние утилиты в процессе сборки. Например, у меня есть проект, который сначала собирает программу на Хаскелле, запускает ее, а она производит код на С++, который уже превращается в конечную программу. На CMake это заняло строчек 10, а на студии мне неизвестно как это реализовать.

То же самое — не критично. 99% проектов обходятся без сторонних утилит в процессе сборки. Если будет критично, то эту функцию добавят в IDE. Предварительный запуск программы на Хаскелле для написания программы на С++ для последующей трансляции это такая ЭКЗОТИКА о которой и говорить не стоит. Так работают даже не 1% программистов, так работают 0.00001% программистов.

Да вобщем-то и сейчас никто не обломится, запустив перед сборкой/после сборки отдельный батник со сторонними утилитами.

Все упомянутые «неудобства» пользования IDE не перевешивают «удобств» пользования IDE. А править вручную конфигурацию для Cmake это то еще удовольствие. Да еще при этом помнить все птичьи правила этого птичьего языка конфигураций.

В общем резюмируя — сборка Unix-style и вообще работа Unix-style времен батьки Денниса Ритчи это для олдскульного поколения, которое успело выучить язык конфигураций make и Cmake до того, как придумали IDE (спасибо за это кстати приснопамятной фирме Borland). Чем дальше, тем меньше остается таких динозавров что и к лучшему. Никто же сейчас не программирует в кодах. А когда-то были специалисты, которые помнили наизусть все коды(!) (даже не мнемоники ассемблера, а КОДЫ) всей системы команд PDP-11. 🙂

Он является генератором сценариев сборки, и таким образом, делает проект переносимым между разными IDE и системами сборки,

Это все очень хорошо, но 99% проектов не нуждаются в переноске между разными IDE и системами сборки. Поэтому это свойство Cmake не востребовано в 99% случаев.

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

Очень сомнительное утверждение.

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

И каким образом использование Cmake помогает версионировать проекты? К тому же для версионирования сейчас используются всякие системы контроля версий типа того же git. Которые тоже ни разу не инструменты командной строки.

так как противопоставлять CMake и IDE неправильно. Это система сборки, которая может использоваться и с IDE.

Может использоваться. А может и не использоваться. И 99% проектов не используют CMake. И 99% программистов не используют CMake. И чем дальше, тем эта цифра будет только расти.

А вопрос был от человека, который счастливо живет под IDE и вдруг узнает что есть еще CMake. Естественно у него возникает вопрос — как же он жил до этого и не пользовался CMake и все у него работало? 🙂 А просто время CMake ушло и CMake остался только для старой гвардии, которая умирает но не сдается (С) Наполеон Бонапарт. 🙂

С развитием хороших и разных IDE роль CMake и благословенной командной строки все время снижается. 🙂

Довольно парадоксально выглядит, что ТС вполне удовлетворен ответом, а общественность продолжает негодовать и рассказывать, что собой представляет Cmake. Вопрос был не о том, что собой представляет Cmake, а вопрос был о том, зачем нужен Cmake, если есть IDE, которые умеют все, что умеет Cmake и таким образом IDE делает Cmake не нужным.

Автомобили заменили лошадей, а IDE вполне заменили Cmake. Это называется технический прогресс. Можно и сейчас ездить на телеге, но зачем? Можно и сейчас собирать проекты с помощью Cmake, но зачем?

Ну то есть понятно зачем. Действительно, существует 1% проектов, которые должны быть переносимы между разными IDE и платформами. Для таких проектов, возможно, применение Cmake и оправдано. Но это не мейнстим сейчас. Это глубоко нишевое применение.

Источник: ru.stackoverflow.com

Введение в CMake

CMake — кроcсплатформенная утилита для автоматической сборки программы из исходного кода. При этом сама CMake непосредственно сборкой не занимается, а представляет из себя front-end. В качестве back-end`a могут выступать различные версии make и Ninja. Так же CMake позволяет создавать проекты для CodeBlocks, Eclipse, KDevelop3, MS VC++ и Xcode. Стоит отметить, что большинство проектов создаются не нативных, а всё с теми же back-end`ами.

Для того что бы собрать проект средствами CMake, необходимо в корне дерева исходников разместить файл CMakeLists.txt, хранящий правила и цели сборки, и произвести несколько простых шагов.
Разберёмся на примерах.

Пример 1. Hello, World:

Для начала напишем простейший хеловорлд и создадим структуру проекта:
main.cpp

#include int main(int argc, char** argv)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. add_executable(main main.cpp) # Создает исполняемый файл с именем main # из исходника main.cpp

Синтаксис CMake похож на синтаксис bash, всё что после символа «#» является комментарием и обрабатываться программой не будет. CMake позволяет не засорять дерево исходных кодов временными файлами — очень просто и без лишних телодвижений сборка производится «Out-of-Source».

Создадим пустую директорию для временных файлов и перейдём туда.

Теперь запустим команду cmake, передав ей в качестве параметра путь к папке с исходниками:

Видим, что в папке появилось несколько временных файлов, необходимых для сборки проекта.
Теперь можно запустить непосредственно make:

Итак, наша программа собралась.
Папку tmp можно очищатьудалять без риска поломать исходники. Если CMakeLists.txt был изменен, то вызов make автоматически запустит cmake. Если исходники были перемещены, то нужно очистить временную директорию и запустить cmake вручную.

Пример 2. Библиотеки:

Если ваш проект содержит библиотеку, то CMake соберет ее без проблем.
Для этого усложним пример.

void hello_world();
foo.cpp
#include void hello_world()
main.cpp
#include «foo.h» int main(int argc, char** argv)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(hello_world) # Название проекта set(SOURCE_EXE main.cpp) # Установка переменной со списком исходников для исполняемого файла set(SOURCE_LIB foo.cpp) # Тоже самое, но для библиотеки add_library(foo STATIC $) # Создание статической библиотеки с именем foo add_executable(main $) # Создает исполняемый файл с именем main target_link_libraries(main foo) # Линковка программы с библиотекой

Переменные могут хранить списки значений, разделённых пробеламитабуляциямипереносами:
set(SOURCE main.cpp foo.cpp) set(HEADER main.h foo.h)

Оба варианта правильные
Что бы получить значение переменной ипользуем конструкцию:

Итак, эта версия нашего проекта включает в себя одну статическую библиотеку, собираемую из исходников. Если заменить «STATIC» на «SHARED», то получим библиотеку динамическую. Если тип библиотеки не указать, по умолчанию она соберётся как статическая.
При линковке указываются все необходимые библиотеки:

target_link_libraries(main foo ogg vorbis)

Как и при ручной компиляции, имена библиотек указываются без стандартного префикса «lib».
Итак, сборка библиотек с CMake не вызывает проблем, при этом тип библиотеки статическаядинамическая меняется лишь одним параметром.

Пример 3. Подпроекты:

Подпроекты очень удобны, если ваша программа разбита на несколько библиотек или же проект состоит из нескольких программ.
Каждый подпроект является по сути полноценным проектом и может использоваться самостоятельно.
Теперь у нас «foo» находится в субдирректории и там же находится CMakeLists.txt подпроекта.

CMakeLists.txt

cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(hello_world) # Название проекта set(SOURCE_EXE main.cpp) # Установка переменной со списком исходников include_directories(foo) # Расположение заголовочных файлов add_executable(main $) # Создает исполняемый файл с именем main add_subdirectory(foo) # Добавление подпроекта, указывается имя дирректории target_link_libraries(main foo) # Линковка программы с библиотекой
main.cpp

#include «foo.h» int main(int argc, char** argv)
foo/CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(foo) # Название проекта set(SOURCE_LIB foo.cpp) # Установка переменной со списком исходников add_library(foo STATIC $)# Создание статической библиотеки
foo/foo.h
void hello_world();
foo/foo.cpp

#include void hello_world()

В файле подпроекта ничего нового для вас нет. А вот в основном файле новые команды:

include_directories(foo)

main.cpp мы не меняли, а foo.h перенесли. Команда указывает компилятору, где искать заголовочные файлы. Может быть вызвана несколько раз. Хидеры будут искаться во всех указаных директориях.

add_subdirectory(foo)

Указываем директорию с подпроектом, который будет собран как самостоятельный.
Вывод: проекты на CMake можно объединять в довольно сложные иерархические структуры, причем каждый подпроект в реальности является самостоятельным проектом, который в свою очередь может сам состоять из подпроектов. Это позволяет легко разбить вашу программу на необходимое количество отдельных модулей. Примером такого подхода может служить KDE.

Пример 4. Поиск библиотек:

CMake обладает достаточно развитыми средствами поиска установленых библиотек, правда они не встроеные, а реализованы в виде отдельных модулей. В стандартной поставке довольно много модулей, но некоторые проекты (например Ogre) поставляют свои. Они позволяют системе автоматически определить наличие необходимых для линковки проекта библиотек.
На debian модули располагаются в /usr/share/cmake-2.8/Modules/ (у вас версия может отличаться). За поиск библиотек отвечают модули, называющиеся FindNAME.cmake, где NAME — имя библиотеки.

find_package(SDL REQUIRED) if(NOT SDL_FOUND) message(SEND_ERROR «Failed to find SDL») return() else() include_directories($) endif() ########################################################## find_package(LibXml2 REQUIRED) if(NOT LIBXML2_FOUND) message(SEND_ERROR «Failed to find LibXml2») return() else() include_directories($) endif() ########################################################## find_package(Boost COMPONENTS thread-mt REQUIRED) if(NOT Boost_FOUND) message(SEND_ERROR «Failed to find boost::thread-mt.») return() else() include_directories($) endif() ########################################################## target_link_libraries($ $ $ $)

Думаю, смысл должен быть понятен. Первый и второй блок — поиск библиотеки. Если в системе её нет, выведется сообщение об ошибке и завершается выполнение cmake. Третий блок похож, только он ищет не целый пакет библиотек, а лишь необходимый компонент. Каждый такой автоматизированый поиск определяет после выполнения как минимум 3 переменные:
SDL_FOUND, LIBXML2_FOUND, Boost_FOUND — признак присутствия бибилиотеки;
SDL_LIBRARY, LIBXML2_LIBRARIES, Boost_LIBRARIES — имена библиотек для линковки;
SDL_INCLUDE_DIR, LIBXML2_INCLUDE_DIR, Boost_INCLUDE_DIRS — пути к заголовочным файлам.
Если с первыми более или менее понятно, то вторые и третьи мне доставили много хлопот — половина имеет имена в единственном числе, половина — во множественном. Но оказалось, это легко отследить. В каждом модуле вначале есть коментарии, там описаны определяемые переменные. Посмотрите, например, /usr/share/cmake-2.8/Modules/FindLibXml2.cmake
Как видите, CMake способен сам определить наличие и местоположение необходимых библиотек и заголовочных файлов. В принципе, это должна уметь любая система автоматической сборки, иначе смысл в ней?

Пример 5. Внешние библиотеки и объектные файлы:

Если вы пишите для «дяди», а злой «дядя» любит самописные библиотеки и делиться исходниками не желает, поэтому присылает готовую библиотеку, то вы по адресу.
Объектные файлы в CMake стоят на ряду с исходниками — достаточно включить объектник в список файлов для компиляции.
С библиотеками потуже. Как известно, статическая библиотека это не что иное, как ar-архив, внутри которого лежат обычные объектники, никак не связаные между собой. Вы, наверное, уже догадались, как я поступал сначала. Да, просто потрошил библиотеку. Но потом был найден способ поэлегантнее:

add_library(netutil STATIC IMPORTED) set_property(TARGET netutil PROPERTY IMPORTED_LOCATION Binary/game_client/libnetutil.a)

Слово «IMPORTED», указывает, что библиотека берётся извне.
В CMake каждая цель имеет параметры, а set_property позволяет их изменять.
Линкуется такая библиотека стандартно:

target_link_libraries($ netutil)

Для динамических библиотек все аналогично, только тип «SHARED», расширение — «.so».
К сожалению, поддержка несистемных библиотек реализована немного костыльно. Возможно, я просто не знаю правильного варианта, поэтому буду рад, если «ткнете мордочкой». С другой стороны это не навороченый экзоскелет с системой жизнеобеспечения, а простейший костыль из двух строк.

Генераторы:

Как было сказано в начале, CMake умеет генерировать множество различных видов проектов. Это удобно и позволяет использовать CMake для практически любой популярной IDE.
Если запустить cmake без параметров, в конце будут описаны доступные генераторы. Пользоваться так:

Заключение:

Это не перевод мануала, а результат использования CMake в одном коммерческом проекте. Буду рад, если статья поможет хотя бы одному человеку — на русском языке подобной документации довольно мало.

• один проект — один файл. Не нужно хранить кучу скриптов настройки, сборки и прочего хлама;
• Скорость работы в сравнении с autotools;
• простой и понятный синтаксис, конечно с элегантностью питона не потягаться, но и не брейнфак, в конце концов.;
• является front-end`ом для множества IDE;
• отображение прогресса — довольно удобно;
• цветной вывод — в серые будни немного краски не помешает;

Источник: habr.com

Полное руководство по CMake. Часть первая: Синтаксис

2018-11-28 в 16:48, admin , рубрики: C, c++, cmake, автоматизация рутины, для начинающих, компиляция, руководство для новичков, руководство для разработчика, руководство для чайников, системы сборки

Введение

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

Язык CMake, будучи транслированным в нативный файл сборки (например, Makefile или Ninja), определяет процесс всего управления проектом. В Вашем распоряжении, с функциональной стороны, есть лишь команды, которые могут образовываться в довольно сложные конструкции. С них мы и начнём.

Запуск CMake

Ниже приведены примеры использования языка CMake, по которым Вам следует попрактиковаться. Экспериментируйте с исходным кодом, меняя существующие команды и добавляя новые. Чтобы запустить данные примеры, следуйте этим шагам:

1. Установите программу CMake с официального сайта
2. Создайте на рабочем столе текстовый файл CMakeLists.txt
3. Добавьте в начало файла cmake_minimum_required(VERSION 3.0)
4. Скопируйте туда исходные тексты необходимых примеров
5. Если у Вас установлен консольный CMake, то запустить скрипт можно с помощью команды » cmake . «. Если у Вас графический CMake, то в первые два верхних поля приложения вбейте адрес Вашего рабочего стола, затем нажмите кнопку Generate . Результат появится в нижнем текстовом поле.

Команды

Команды в CMake подобны функциям во многих языках программирования. Чтобы вызвать команду, необходимо написать её имя, а затем передать ей обрамлённые в круглые скобки аргументы, отделённые символами пробелов. В приведённом примере команде message передаются шесть аргументов для вывода в консоль:

# Напечатает в консоль «CMake is the most powerful buildsystem!» message(«CMake » «is » «the » «most » «powerful » «buildsystem!»)

Аргументы

Аргументы, обрамлённые в двоёные кавычки, позволяют внутри себя совершать экранирование и подстановку переменных. Необрамлённые аргументы не позволяют производить подобных вещей и не могут включать в себя символов ()#» и пробелов, однако более удобны для использования. Пример:

# Напечатает «Hello, my lovely CMake», один таб и «!»: message(«Hello, my lovely CMaket!») # Напечатает «Hello,_my_lovely_CMake!» без пробелов: message(Hello,_my_lovely_CMake!)

Комментарии

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

Переменные

Переменные можно определить путём вызова команды set , а удалить вызовом unset . Получить значение переменной можно по конструкции $ . Пример:

# Определить переменную VARIABLE со значением «Mr. Thomas»: set(VARIABLE «Mr. Thomas») # Напечает «His name is: Mr. Thomas»: message(«His name is: » $) # Удалить переменную VARIABLE: unset(VARIABLE)

Логические выражения

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

Логические выражения используются при проверки условий и могут принимать одно из двух значений: правда или ложь. Например, выражение 52 LESS 58 обратится в правду, так как 52 < 58. Выражение 88 EQUAL 88 обратится в правду, 63 GREATER 104 обратится в ложь. Сравнивать можно не только числа, но и строки, версии, файлы, принадлежность к списку и регулярные выражения. Полный список логических выражений можно посмотреть тут.

Условные операторы

Условные операторы в CMake работают в точности как в других языках программирования. В данном примере сработает лишь первый условный оператор, который проверяет, что 5 > 1. Второе и третье условия ложны, так как 5 не может быть меньше или равняться одному. Блоки команд elseif(5 LESS 1) и else() необязательны, а endif() обязательна и сигнализирует о завершении предыдущих проверок.

# Напечатает «Of course, 5 > 1!»: if(5 GREATER 1) message(«Of course, 5 > 1!») elseif(5 LESS 1) message(«Oh no, 5 < 1!») else() message(«Oh my god, 5 == 1!») endif()

Циклы

Циклы в CMake подобны циклам других языков программирования. В приведённом примере устанавливается значение переменной VARIABLE в Airport , а затем четыре вложенные команды последовательно исполняются пока значение переменной VARIABLE будет равняться Airport . Последняя четвёртая команда set(VARIABLE «Police station») устанавливает значение проверяемой переменной в Police station , поэтому цикл сразу остановится, не дойдя до второй итерации. Команда endwhile() сигнализирует о завершении списка вложенных в цикл команд.

# Напечатает в консоль три раза «VARIABLE is still ‘Airport'»: set(VARIABLE Airport) while($ STREQUAL Airport) message(«VARIABLE is still ‘$'») message(«VARIABLE is still ‘$'») message(«VARIABLE is still ‘$'») set(VARIABLE «Police station») endwhile()