Как сделать комментарий в cmake

Добавил пользователь Alex
Обновлено: 10.09.2024

Для чего мне может понадобится CMake? Для быстрой компиляции?

В двух словах -- для полного контроля над процессом сборки. Пишете все руками и сами отвечаете за свои действия. Т.е. это инструмент профессионалов

По просьбе @pepsicoca1 пишу развернутый пост.

Компилятор

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

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

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

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

make

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

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

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

make – maintain program dependencies

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

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

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

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

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

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

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

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

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

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

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

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

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

CMake vs IDE

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

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

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

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

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

Философия

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

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

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

@Qwertiy [были шаги prebuild и postbuild] Так давно все сделано! Впрочем это логично, сделать это в IDE ничего не стоит. Вот насколько это никому не нужно, что я даже и не обращал внимания что там есть шаги prebuild и postbuild. :-)

@RundogieRundogie Потратили вы два дня потому что у вас опыта мало. Ну и отчасти потому что там система сборки какая-то неведомая - premake. Еще раз, если бы 100% разработчиков пользовали бы студию, то нужды в CMake бы не было. Но объективная реальность такова, что в ней куча IDE и у всех свои форматы проектов. Нужен какой-то общий знаменатель и этот знаменатель - CMake.

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

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

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

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

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

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.

@RundogieRundogie Я в Сях не шарю и заглянул сюда лишь из любопытства, но насколько мне известно, билдер и компилятор - это совершенно разные вещи. Компилятор превращает в исполняемый код программу, которая собирается билдером из файлов проекта.

@RundogieRundogie зависит от IDE. В Visual Studio - да. Но есть IDE, которые используют компилятор и систему сборки, поставленные отдельно.

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


не надо путать 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: приведите пример.

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

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

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

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

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

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

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

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

В общем резюмируя - сборка 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 и оправдано. Но это не мейнстим сейчас. Это глубоко нишевое применение.

Многие, кто начинал создавать собственные программы, пользовался какой-либо системой сборки. В общем, система сборки – это набор инструментов, облегчающий работу с компилятором. Это включает в себя компиляцию, линковку, установку, а также сбор исходных файлов для передачи их компилятору и слежение за зависимостями. Также современные системы сборки облегчают работу с библиотеками, позволяют создавать переносимые проекты и выполняют ещё массу других вкусностей. Эта статья посвящена популярной системе сборки CMake и расскажет, как правильно её установить и настроить, а также будет рассмотрен простой пример её использования. Она рассчитана на тех, что хоть немного знаком с понятиями make, Makefile, компиляция, линковка.

Установка в Linux.

Если же в репозитории нет такого пакета, то можно его собрать вручную. Скачиваем Unix/Linux Source, например, cmake-3.5.0-rc3.tar.gz, распаковываем и собираем:

Если нет необходимости устанавливать в системную /usr директорию, можно в аргументе —prefix прописать нужный корень установки. По умолчанию, без явного указания —prefix, установка будет произведена в /usr/local. -j используется для ускорения сборки, например, на 4-х ядерном процессоре можно указать -j4, и сборка будет вестись параллельно в 4 потока.

Установка в Windows.

Для Windows на сайте CMake лежит установочный файл msi. Рекомендую при установке отметить галочку добавления пути в переменные окружения PATH для всех пользователей. Тогда, после перелогинивания, CMake будет доступен из любого места. Проверить можно, открыв cmd и выполнив тот же

Я довольно новичок в cmake, и прочитал несколько учебников о том, как его использовать, и написал несколько сложных 50 строк сценария CMake, чтобы сделать программу для 3 разных компиляторов. Это, вероятно, завершает все мои знания в cmake.

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

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

Теперь я перешел на другой компьютер и перекомпилировал CMake 2.8.11.2,и я почти вернулся к квадрату! Он всегда компилирует вещь в папку src, где мои CMakeLists.расположенном txt-это.

часть, где я выбираю каталог в моем скрипте cmake это:

и теперь это всегда заканчивается:

Я что-то пропустила?

нет необходимости устанавливать все переменные, которые вы устанавливаете. CMake устанавливает разумные значения по умолчанию. Вы должны определенно не изменить CMAKE_BINARY_DIR или CMAKE_CACHEFILE_DIR . Рассматривайте их как только для чтения.

Сначала удалите существующий проблемный файл кэша из каталога src:

затем удалите все set() команды и делать:

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

после этого вы можете посмотреть, где CMake ставит вещи по умолчанию, и только если вы не удовлетворены местоположениями по умолчанию (например, значением по умолчанию EXECUTABLE_OUTPUT_PATH ), измените только те, которые вам нужны. И попытайтесь выразить их относительно CMAKE_BINARY_DIR , CMAKE_CURRENT_BINARY_DIR , PROJECT_BINARY_DIR etc.

если вы посмотрите документацию CMake, вы увидите переменные, разбитые на семантические разделы. Кроме очень особые обстоятельства, вы должны рассматривать все перечисленные в разделе "переменные, которые предоставляют информацию" только для чтения внутри CMakeLists.

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

делай то, что ты делал, беги

что заставит cmake генерировать построить дерево на /path/to/my/build/folder на источник дерева на /path/to/my/source/folder .

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

если ваш текущий каталог уже находится в папке build.

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

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

поскольку сборки вне источника часто более желательны, чем сборки внутри источника, вы можете изменить свой cmake, чтобы потребовать от источника строит:

макрос из часто используемых модуль под названием MacroOutOfSourceBuild . Существует множество источников для MacroOutOfSourceBuild.cmake в google, но я не могу найти оригинал, и он достаточно короткий, чтобы включить его здесь полностью.

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

вы можете найти его полезно установить пути, по которым записываются двоичные файлы, общие и статические библиотеки - в этом случае см. как сделать вывод cmake в " bin " dir? (отказ от ответственности, у меня есть верхний голосованный ответ на этот вопрос. но именно так я узнал об этом).

по состоянию на CMake Wiki:

CMAKE_BINARY_DIR если вы создаете in-source, это то же самое, что и CMAKE_SOURCE_DIR, иначе это каталог верхнего уровня вашего построить дерево

сравните эти две переменные, чтобы определить, была ли запущена сборка вне источника

прежде всего, вы не должны ретранслировать имя dir сборки в своем скрипте. линии ../ Компиляция должна быть изменена.

Это потому, что это зависит от пользователя, где компилировать.

превращая мой комментарий в ответ:

в случае, если кто-то сделал то, что я сделал, который начал с размещения всех файлов сборки в исходном каталоге:

cmake поместит кучу файлов сборки и файлов кэша ( CMakeCache.txt , CMakeFiles , cmake_install.cmake , etc) в src реж.

чтобы перейти на исходную сборку, мне пришлось удалить все эти файлы. Тогда я мог бы сделать то, что @Agnew рекомендовал в своем ответе:

CMake позволяет быстро и удобно писать сборочные скрипты для кроссплатформенной сборки программных проектов. Под Windows генерируются проекты для Visual Studio, под Linux - Makefiles. Поддерживаются и другие среды разработки.

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

Поиск библиотек

Для подключения внешней библиотеки нужно как минимум указать компилятору путь к заголовочным файлам и линкеру - к самой библиотеке (.lib, .so). CMake может попробовать найти эти пути с помощью команд find_path и find_library, которые в простейшей форме выглядят так:

Если файл с именем имя_заголовочного_файла будет найден, то в переменную ПЕРЕМЕННАЯ1 будет записан полный путь к директории, где этот файл лежит. Если файл с именем имя_библиотеки будет найден, то в переменную ПЕРЕМЕННАЯ2 будет записан полный путь к этому файлу.

После этого эти переменные можно будет подключить к цели сборки:

Но вот только где CMake будет производить поиск? Можно указать несколько стандартных путей, например так:

Это хорошо работает под Линуксом, где все библиотеки обычно лежат по нескольким стандартным путям. Под Windows хуже: нужная библиотека может располагаться, где угодно.

Можно договориться, что при установке библиотеки на компьютер путь к ней будет прописываться в переменную окружения ПЕРЕМЕННАЯ_ОКРУЖЕНИЯ, тогда CMake сможет это использовать:

Если ничего не помогло, то пользователю придется вручную вводить в интерфейсе CMake нужные пути.

Упрощение поиска

Для сложных сторонних библиотек с кучей модулей и версий может понадобиться большое нагромождение команд find_path и find_library. Для удобства эти команды можно выделить в отдельный скрипт с именем FindБИБЛИОТЕКА.cmake.

После этого можно вызывать скрипт командой find_package:

(и не забыть прописать в переменной CMAKE_MODULE_PATH путь к папке со скриптами).

Это серьезно упрощает структуру корневого файла CMakeLists.txt. Также для популярных библиотек уже существуют скрипты для поиска, которые устанавливаются вместе с CMake. Под Линуксом такие скрипты лежат в папке /usr/share/cmake/Modules, а под Windows в папке C:\Program Files (x86)\CMake\share\cmake-3.2\Modules.

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

Импорт целей сборки

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

Создать и описать импортированную цель сборки можно с помощью ключевого слова IMPORTED. Пример:

После этого можно подключить эту внешюю цель сборки к нашей цели:

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

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

Тогда нашему проекту достаточно будет подключить готовый скрипт:

Сборка зависимостей

Но что, если в системе не установлена нужная зависимость? Можно попросить пользователя установить её, либо поручить это CMake-скрипту.

Есть 2 основные стратегии в зависимости от размера внешней библиотеки.

Исходный код маленькой библиотеки можно просто добавить в дерево исходников нашего проекта, например, в подпапку 3rdParty. Далее библиотеку можно подключить в из корневого файла CMakeLists.txt с помощью команды add_subdirectory:

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

Если внешняя библиотека слишком большая, то можно использовать команду ExternalProject_Add. Например:

Команда имеет множество параметров. Она позволяет скачать архив из интернета и распаковать его, либо клонировать репозиторий, вызвать отдельный экземпляр CMake для создания проектов Visual Studio или Makefiles. Такой многофункциональный комбайн.

Однако, команда имеет и недостатки. Дело в том, что конфигурирование и сборка внешней библиотеки происходят не во время ExternalProject_Add. Они происходят одновременно со сборкой нашего проекта, а значит до начала сборки ни самих библиотек, ни заголовочных файлов, ни скриптов не существует. А это значит, что команды find_library, find_path будут выдавать ошибки при конфигурировании в CMake. Цели сборки внешней библиотеки будут недоступны…

Поэтому команда ExternalProject_Add не является панацеей и её нужно использовать осторожно.

Суперсборка

Идея в том, что и сторонние библиотеки, и наш проект собирать с помощью ExternalProject_Add. Корневой CMakeLists.txt просто содержит вызовы этой команды и всё.

В этом случае скачивание и конфигурирование происходит во время сборки. Когда мы вызываем команду make под Линуксом или запускаем сборку в Visual Studio под Windows, то происходит следующее:

З.Ы. program и file.c - нарочно измененные имена. Добавление -lasound после -std=c99 не приводит к какому-либо результату.



CMake — неочевидное говно потому что.


ОМГ, да они там совсем поехавшие

если надо это вручную указывать, зачем тогда вообще нужен этот cmake?


но когда через год два или просто чужой проект на смейке надо менять конфиги-то это просто ад

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


когда через год два или просто чужой проект на смейке надо менять конфиги-то это просто ад

получается, что таки использовать нельзя? или можно?

ОФФТОПИК: глазами видел толстые монструозные проекты на одних только мейкфайлах, и ничего, как-то живут.


если надо это вручную указывать, зачем тогда вообще нужен этот cmake?


угу, уже заметил

кстати, set_property корректно работает если разместить после add_executable

иначе ругается на

Error:set_property could not find TARGET program. Perhaps it has not yet been created.

а еще, не знаешь как грамотно указывать -Wall и -Werror?


Кстати set_property(TARGET program PROPERTY C_STANDARD 99) только недавно ввели, то этого нужно было делать такой костыль:

Увы, ничего лучше говноCMake'а так и не придумали. QBS вот неплохой, не использует тот же make, а компилит сам в несколько потоков. Но там Qt, сам понимаешь.


кстати, set_property корректно работает если разместить после add_executable

Ага, я на память писал. Уже не помню всех этих херанутых премудростей CMake'а.

а еще, не знаешь как грамотно указывать -Wall и -Werror?

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


ничего лучше говноCMake'а так и не придумали

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


Увы, ничего лучше говноCMake'а так и не придумали.

Давно есть GNU Make со встроенным Guile.


CMake обычно используют кросс-платформенные проекты.


CMake обычно используют кросс-платформенные проекты.

Я его юзаю только потом, что Clion под него заточен, а лучшего IDE я пока не нашел (сейчас в треде появятся адепты [g]vim + cscope).

Конечно, я могу переключаться в консольку и выполнять make, но блин. 21 век на дворе!


Qt Creator, к примеру. Кроме CMake держит Makefile, QMake, QBS, Autotools. Для сишки/плюсов отличное и легковесное IDE. Хотя бы не тормозит, как этот самый CLion.


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

От сложности проекта зависит. Всякие автотулзы не на ровном месте выросли же.


Тебе просто странный совет дали.

pkg_check_modules может сразу много pkg-config модулей за раз искать.

Для некоторых библиотек есть готовые скрипты, как для pkg-config. Тогда используешь find_package(), с параметрами из описания тех скриптов. Например:

i-rinat ????? ( 26.06.16 01:37:33 )
Последнее исправление: i-rinat 26.06.16 01:39:41 (всего исправлений: 1)

CMake и правда несколько долбанут. Писали админы похоже. Попахивает башом и перлятиной.

Ну не всё так плохо. Мой cmake за полчаса научился сам выкачивать и собирать зависимость основного проекта, а там autotools было в то время (сейчас cmake), причём мне на самом деле пришлось почитать документацию. Из того, что ты пообсираешь лучшую на сегодняшний систему сборки из представленных, ничего хорошего не выйдет.



Нет, не нужно. EXL некомпетентен, но пытается давать советы.


а еще, не знаешь как грамотно указывать -Wall и -Werror?

Вышеприведённое для флагов компилятора. Для препроцессора COMPILE_DEFINITIONS, target_compile_definitions() и add_definitions(). И так далее с include_directories, link_directories и link_libraries.

Про pkg-config уже написали.

Про -std= можно через свойство C_STANDARD, если нужно 1) кроссплатформенно и 2) чтобы оно само проверило поддержку стандарта, а можно как написано выше, если переносимость на !GCC не важна.

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

intelfx ????? ( 26.06.16 02:28:26 )
Последнее исправление: intelfx 26.06.16 02:36:58 (всего исправлений: 4)


Ниже просмотри тред.

Я вставил link_directories(/usr/lib) специально, чтобы ТС в будущем не задавал вопросов, мол как подлинковать библиотеку из соседнего каталога, не устанавливая её в систему.

PkgConfig — хорошо, но только в GNU/Linux. CMakeLists.txt, наводнённый лапшой из pkg_check_modules по опыту KDE'шников весьма паршиво работает в том же MS Windows. А CMake задумывался как кросс-платформенная система сборки.


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

CMake настолько удобный, очевидный и понятный, что на ЛОРе каждый месяц появляются треды с его обосрамсами, вот, недавний, майский: Cmake Qt 5.6 undefined reference to vtable

TL;DR: Проект не собирается, если *.cpp и *.h лежат в разных директориях.

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

Но других же не заставишь иметь да уметь. А вот расхлёбывать самому.


А ещё регистронезависимость — полное говно.

Открываешь CMakeLists.txt в разных проектах (а то и в одном и том же) и видишь:

Сразу вспоминается DOS, Windows с его


Но ТС линкуется с libalsa! Там, где нет pkg-config, libalsa тоже нет.


Да, давай, расскажи мне, как CMake должен собрать *.moc-файлы и прилинковать их, если ТС-нуб не осилил прочитать доку на кьют и добавить $MOC_SOURCES в список файлов для компиляции.

Через libastral, не иначе.

intelfx ????? ( 26.06.16 03:06:24 )
Последнее исправление: intelfx 26.06.16 03:12:14 (всего исправлений: 3)


Я почему-то решил, что у ТС просто демонстрационный пример.


А это кстати кроссплатформенно? Мне на тачке с MS Windows -> MSVC оно развернётся в /Wall /WX ?


Нет, не кроссплатформенно.


Используй Waf, чо.


Вот, кстати было бы полезно сделать хотя бы базовые уровни предупреждений кроссплатформенно (без предупреждений/вывод всех предупреждений/предупреждения как ошибки).

Читайте также: