Введение в 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:
Синтаксис CMake похож на синтаксис bash, всё что после символа «#» является комментарием и обрабатываться программой не будет. CMake позволяет не засорять дерево исходных кодов временными файлами — очень просто и без лишних телодвижений сборка производится «Out-of-Source».
Создадим пустую директорию для временных файлов и перейдём туда.
$ mkdir tmp
fshp@panica-desktop:
$ cd tmp/
fshp@panica-desktop:
/cmake/example_1/
…
— Build files have been written to: /home/fshp/tmp
fshp@panica-desktop:
/tmp$ ls
CMakeCache.txt CMakeFiles cmake_install.cmake Makefile
fshp@panica-desktop:
/tmp$ make
Scanning dependencies of target main
[100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
Linking CXX executable main
[100%] Built target main
fshp@panica-desktop:
/tmp$ ./main
Hello, World!
fshp@panica-desktop:
Итак, наша программа собралась.
Папку tmp можно очищать\удалять без риска поломать исходники. Если CMakeLists.txt был изменен, то вызов make автоматически запустит cmake. Если исходники были перемещены, то нужно очистить временную директорию и запустить cmake вручную.
Пример 2. Библиотеки:
Переменные могут хранить списки значений, разделённых пробелами\табуляциями\переносами:
Оба варианта правильные
Что бы получить значение переменной ипользуем конструкцию:
Итак, эта версия нашего проекта включает в себя одну статическую библиотеку, собираемую из исходников. Если заменить «STATIC» на «SHARED», то получим библиотеку динамическую. Если тип библиотеки не указать, по умолчанию она соберётся как статическая.
При линковке указываются все необходимые библиотеки:
Как и при ручной компиляции, имена библиотек указываются без стандартного префикса «lib».
Итак, сборка библиотек с CMake не вызывает проблем, при этом тип библиотеки статическая\динамическая меняется лишь одним параметром.
Пример 3. Подпроекты:
В файле подпроекта ничего нового для вас нет. А вот в основном файле новые команды:
main.cpp мы не меняли, а foo.h перенесли. Команда указывает компилятору, где искать заголовочные файлы. Может быть вызвана несколько раз. Хидеры будут искаться во всех указаных директориях.
Указываем директорию с подпроектом, который будет собран как самостоятельный.
Вывод: проекты на CMake можно объединять в довольно сложные иерархические структуры, причем каждый подпроект в реальности является самостоятельным проектом, который в свою очередь может сам состоять из подпроектов. Это позволяет легко разбить вашу программу на необходимое количество отдельных модулей. Примером такого подхода может служить KDE.
Пример 4. Поиск библиотек:
CMake обладает достаточно развитыми средствами поиска установленых библиотек, правда они не встроеные, а реализованы в виде отдельных модулей. В стандартной поставке довольно много модулей, но некоторые проекты (например Ogre) поставляют свои. Они позволяют системе автоматически определить наличие необходимых для линковки проекта библиотек.
На debian модули располагаются в /usr/share/cmake-2.8/Modules/ (у вас версия может отличаться). За поиск библиотек отвечают модули, называющиеся FindNAME.cmake, где NAME — имя библиотеки.
Думаю, смысл должен быть понятен. Первый и второй блок — поиск библиотеки. Если в системе её нет, выведется сообщение об ошибке и завершается выполнение 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-архив, внутри которого лежат обычные объектники, никак не связаные между собой. Вы, наверное, уже догадались, как я поступал сначала. Да, просто потрошил библиотеку. Но потом был найден способ поэлегантнее:
Слово «IMPORTED», указывает, что библиотека берётся извне.
В CMake каждая цель имеет параметры, а set_property позволяет их изменять.
Линкуется такая библиотека стандартно:
Для динамических библиотек все аналогично, только тип «SHARED», расширение — «.so».
К сожалению, поддержка несистемных библиотек реализована немного костыльно. Возможно, я просто не знаю правильного варианта, поэтому буду рад, если «ткнете мордочкой». С другой стороны это не навороченый экзоскелет с системой жизнеобеспечения, а простейший костыль из двух строк.
Генераторы:
/cmake/example_3/ -G «KDevelop3 — Unix Makefiles»
Заключение:
Это не перевод мануала, а результат использования CMake в одном коммерческом проекте. Буду рад, если статья поможет хотя бы одному человеку — на русском языке подобной документации довольно мало.
Чем понравился CMake лично мне:
- один проект — один файл. Не нужно хранить кучу скриптов настройки, сборки и прочего хлама;
- Скорость работы в сравнении с autotools;
- простой и понятный синтаксис, конечно с элегантностью питона не потягаться, но и не брейнфак, в конце концов.;
- является front-end`ом для множества IDE;
- отображение прогресса — довольно удобно;
- цветной вывод — в серые будни немного краски не помешает;
Для Sublime Text есть плагин, добавляющий подсветку синтаксиса CMake, он так и называется — «CMake».
Примеры
Источник
add_library¶
Add a library to the project using the specified source files.
Normal Libraries¶
Adds a library target called to be built from the source files listed in the command invocation. The corresponds to the logical target name and must be globally unique within a project. The actual file name of the library built is constructed based on conventions of the native platform (such as lib .a or .lib ).
New in version 3.1: Source arguments to add_library may use «generator expressions» with the syntax $ . See the cmake-generator-expressions(7) manual for available expressions.
New in version 3.11: The source files can be omitted if they are added later using target_sources() .
STATIC , SHARED , or MODULE may be given to specify the type of library to be created. STATIC libraries are archives of object files for use when linking other targets. SHARED libraries are linked dynamically and loaded at runtime. MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality. If no type is given explicitly the type is STATIC or SHARED based on whether the current value of the variable BUILD_SHARED_LIBS is ON . For SHARED and MODULE libraries the POSITION_INDEPENDENT_CODE target property is set to ON automatically. A SHARED library may be marked with the FRAMEWORK target property to create an macOS Framework.
New in version 3.8: A STATIC library may be marked with the FRAMEWORK target property to create a static Framework.
If a library does not export any symbols, it must not be declared as a SHARED library. For example, a Windows resource DLL or a managed C++/CLI DLL that exports no unmanaged symbols would need to be a MODULE library. This is because CMake expects a SHARED library to always have an associated import library on Windows.
By default the library file will be created in the build tree directory corresponding to the source tree directory in which the command was invoked. See documentation of the ARCHIVE_OUTPUT_DIRECTORY , LIBRARY_OUTPUT_DIRECTORY , and RUNTIME_OUTPUT_DIRECTORY target properties to change this location. See documentation of the OUTPUT_NAME target property to change the part of the final file name.
If EXCLUDE_FROM_ALL is given the corresponding property will be set on the created target. See documentation of the EXCLUDE_FROM_ALL target property for details.
See the cmake-buildsystem(7) manual for more on defining buildsystem properties.
See also HEADER_FILE_ONLY on what to do if some sources are pre-processed, and you want to have the original sources reachable from within IDE.
Object Libraries¶
Creates an Object Library . An object library compiles source files but does not archive or link their object files into a library. Instead other targets created by add_library() or add_executable() may reference the objects using an expression of the form $ as a source, where objlib is the object library name. For example:
will include objlib’s object files in a library and an executable along with those compiled from their own sources. Object libraries may contain only sources that compile, header files, and other files that would not affect linking of a normal library (e.g. .txt ). They may contain custom commands generating such sources, but not PRE_BUILD , PRE_LINK , or POST_BUILD commands. Some native build systems (such as Xcode) may not like targets that have only object files, so consider adding at least one real source file to any target that references $ .
New in version 3.12: Object libraries can be linked to with target_link_libraries() .
Interface Libraries¶
Creates an Interface Library . An INTERFACE library target does not compile sources and does not produce a library artifact on disk. However, it may have properties set on it and it may be installed and exported. Typically, INTERFACE_* properties are populated on an interface target using the commands:
and then it is used as an argument to target_link_libraries() like any other target.
An interface library created with the above signature has no source files itself and is not included as a target in the generated buildsystem.
New in version 3.15: An interface library can have PUBLIC_HEADER and PRIVATE_HEADER properties. The headers specified by those properties can be installed using the install(TARGETS) command.
New in version 3.19: An interface library target may be created with source files:
Source files may be listed directly in the add_library call or added later by calls to target_sources() with the PRIVATE or PUBLIC keywords.
If an interface library has source files (i.e. the SOURCES target property is set), it will appear in the generated buildsystem as a build target much like a target defined by the add_custom_target() command. It does not compile any sources, but does contain build rules for custom commands created by the add_custom_command() command.
In most command signatures where the INTERFACE keyword appears, the items listed after it only become part of that target’s usage requirements and are not part of the target’s own settings. However, in this signature of add_library , the INTERFACE keyword refers to the library type only. Sources listed after it in the add_library call are PRIVATE to the interface library and do not appear in its INTERFACE_SOURCES target property.
Imported Libraries¶
Creates an IMPORTED library target called . No rules are generated to build it, and the IMPORTED target property is True . The target name has scope in the directory in which it is created and below, but the GLOBAL option extends visibility. It may be referenced like any target built within the project. IMPORTED libraries are useful for convenient reference from commands like target_link_libraries() . Details about the imported library are specified by setting properties whose names begin in IMPORTED_ and INTERFACE_ .
The must be one of:
STATIC , SHARED , MODULE , UNKNOWN
References a library file located outside the project. The IMPORTED_LOCATION target property (or its per-configuration variant «> » title=»IMPORTED_LOCATION_ «> IMPORTED_LOCATION_ ) specifies the location of the main library file on disk:
For a SHARED library on most non-Windows platforms, the main library file is the .so or .dylib file used by both linkers and dynamic loaders. If the referenced library file has a SONAME (or on macOS, has a LC_ID_DYLIB starting in @rpath/ ), the value of that field should be set in the IMPORTED_SONAME target property. If the referenced library file does not have a SONAME , but the platform supports it, then the IMPORTED_NO_SONAME target property should be set.
For a SHARED library on Windows, the IMPORTED_IMPLIB target property (or its per-configuration variant «> » title=»IMPORTED_IMPLIB_ «> IMPORTED_IMPLIB_ ) specifies the location of the DLL import library file ( .lib or .dll.a ) on disk, and the IMPORTED_LOCATION is the location of the .dll runtime library (and is optional).
Additional usage requirements may be specified in INTERFACE_* properties.
An UNKNOWN library type is typically only used in the implementation of Find Modules . It allows the path to an imported library (often found using the find_library() command) to be used without having to know what type of library it is. This is especially useful on Windows where a static library and a DLL’s import library both have the same file extension.
References a set of object files located outside the project. The IMPORTED_OBJECTS target property (or its per-configuration variant «> » title=»IMPORTED_OBJECTS_ «> IMPORTED_OBJECTS_ ) specifies the locations of object files on disk. Additional usage requirements may be specified in INTERFACE_* properties.
Does not reference any library or object files on disk, but may specify usage requirements in INTERFACE_* properties.
See documentation of the IMPORTED_* and INTERFACE_* properties for more information.
Alias Libraries¶
Creates an Alias Target , such that can be used to refer to in subsequent commands. The does not appear in the generated buildsystem as a make target. The may not be an ALIAS .
New in version 3.11: An ALIAS can target a GLOBAL Imported Target
New in version 3.18: An ALIAS can target a non- GLOBAL Imported Target. Such alias is scoped to the directory in which it is created and below. The ALIAS_GLOBAL target property can be used to check if the alias is global or not.
ALIAS targets can be used as linkable targets and as targets to read properties from. They can also be tested for existence with the regular if(TARGET) subcommand. The may not be used to modify properties of , that is, it may not be used as the operand of set_property() , set_target_properties() , target_link_libraries() etc. An ALIAS target may not be installed or exported.
Источник
