Как узнать компилятор c visual studio

Как посмотреть команду компиляции которую выполняет Visual Studio

На вкладке Tools → Options → Build and Run доступны настройки детализации сообщений MSBuild при сборке. По-умолчанию там выставлена минимальная детализации, но при желании ее можно поднять до уровня «Detailed» или выше, тогда будут выводиться и выполняемые команды.

Отслеживать
ответ дан 22 янв 2021 в 10:43
user7860670 user7860670
29.6k 3 3 золотых знака 17 17 серебряных знаков 36 36 бронзовых знаков

• c++
• c
• visual-studio
• visual-c++

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.11.15.1019

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

0.12 – Настройка компилятора: выбор стандарта языка C++

Поскольку доступно множество различных версий C++ (C++98, C++03, C++11, C++14, C++17 и т. д.), как ваш компилятор узнает, какую из них использовать? Как правило, компилятор выбирает стандарт по умолчанию (часто не самый последний стандарт языка). Если вы хотите использовать другой стандарт, вам необходимо изменить настройки вашей IDE/компилятора. Эти настройки применяются только к активному проекту. При создании нового проекта их необходимо установить заново.

Мы используем C++17. Если ваш компилятор не поддерживает C++17, вы не сможете полностью пройти все уроки, хотя с большинством из них у вас не будет проблем. Убедитесь, что вы используете последнюю версию компилятора, чтобы вы могли самостоятельно скомпилировать все примеры. В конце этого урока есть пример, который вы можете использовать, чтобы проверить, правильно ли вы настроили компилятор.

Кодовые названия для разрабатываемых стандартов языка C++

Обратите внимание, что стандарты языка C++ названы по годам, в которые они были приняты (например, C++ 17 был завершен в 2017 году).

Однако, когда идет согласование нового языкового стандарта, неясно, в каком году состоится его окончательная доработка. Следовательно, незавершенным языковым стандартам присваиваются кодовые названия, которые затем, после завершения стандарта, заменяются фактическими названиями. Например, C++11 во время разработки назывался c++1x. Вы по-прежнему можете встречать эти кодовые названия (особенно для будущей версии языкового стандарта, у которой еще нет окончательного названия).

Вот сопоставление кодовых названий с конечными названиями:

• c++1x = C++11
• c++1y = C++14
• c++1z = C++17
• c++2a = C++20

Например, если вы видите c++1z, это синоним стандарта языка C++17.

Настройка стандарта языка C++ в Visual Studio

На момент написания Visual Studio 2019 по умолчанию использует возможности C++14, что не позволяет использовать новые функции, представленные в C++17 (и C++20), некоторые из которых будут рассмотрены в будущих уроках.

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

Для этого откройте свой проект, затем перейдите в меню Проект (Project) → Свойства (Properties) (имя вашего приложения), затем откройте Свойства конфигурации (Configuration Properties) → C/C++ → Язык (Language).

Там вы можете установить стандарт языка C++ на ту версию C++, которую хотите использовать.

На момент написания мы рекомендуем выбрать «Стандарт ISO C++17 (/std:c++17)» (ISO C++17 Standard (/std:c++17)), который является последним стабильным стандартом.

Если вы хотите поэкспериментировать с возможностями будущего языкового стандарта C++20, выберите «Предварительная версия – функции из последнего рабочего черновика C++ (/std:c++latest)» (ISO C++Latest (/std:c++latest)). Просто обратите внимание, что поддержка может быть нестабильной или глючной.

Настройка стандарта языка C++ в Code::Blocks

Code::Blocks может по умолчанию использовать языковой стандарт до C++11. Обязательно проверьте и убедитесь, что включен более современный языковой стандарт.

Хорошая новость заключается в том, что Code::Blocks позволяет установить языковой стандарт глобально, поэтому вы можете настроить его один раз (а не для каждого проекта). Для этого перейдите в меню Settings (Настройки) → Compiler (Компилятор):

Затем найдите поле или поля с надписью «Have g++ follow the C++XX ISO C++ language standard [-std=c++XX]», где XX – это 11, 14 или другое большее число (смотрите элементы внутри прямоугольников на скриншоте ниже):

Отметьте тот, у которого наибольшее число (на изображении выше это вариант C++17 внутри синего прямоугольника).

Ваша версия Code::Blocks может также поддерживать будущие (или только что выпущенные) версии C++. Если это так, они будут помечены как «Have g++ follow the coming C++XX (aka C++YY) ISO C++ language standard [-std=c++XX]» (синий прямоугольник на скриншоте ниже). При желании вы можете включить их, если хотите использовать функции, добавленные в этих версиях, но обратите внимание, что поддержка может быть неполной (т.е. некоторые функции могут отсутствовать).

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

Например, если вы хотите включить возможности C++17, а в ваших настройках нет параметра C++17, найдите -std=c++1z (кодовое название для C++17).

Кроме того, вы можете перейти на вкладку «Other Compiler Options» (Другие параметры компилятора) и ввести -std=c++17 .

Примечание

Это будет работать, если ваш компилятор поддерживает C++17. Если вы используете старую версию Code::Blocks, и функции C++17 не работают, обновите компилятор.

Установка языкового стандарта в g++

Для GCC/G++ вы можете передать флаги компилятора -std=c++11 , -std=c++14 , -std=c++17 или -std=c++2a , чтобы включить C++11/14/17/2a соответственно.

Тестирование вашего компилятора

После включения C++17 или выше вы сможете скомпилировать следующий код без каких-либо предупреждений или ошибок.

#include #include #include #include #include namespace a::b::c < inline constexpr std::string_view str< "hello" >; > template std::tuple> sum(T. args) < return < sizeof. (T), (args + . ) >; > int main() < auto [iNumbers, iSum]< sum(1, 2, 3) >; std::cout ; std::cout

Если вы не можете скомпилировать этот код, то вы либо не включили C++17, либо ваш компилятор не полностью его поддерживает. В последнем случае установите последнюю версию вашей IDE/компилятора, как описано в уроке «0.6 – Интегрированная среда разработки (IDE)».

Как узнать компилятор c visual studio

PostgreSQL может быть собран с помощью компилятора Visual C++ от Microsoft. Этот компилятор есть в пакетах Visual Studio , Visual Studio Express и в некоторых версиях Microsoft Windows SDK . Если у вас ещё не установлена среда Visual Studio , проще всего будет использовать компиляторы из Visual Studio 2022 или из Windows SDK 10 , которые Microsoft распространяет бесплатно.

С применением инструментария Microsoft Compiler возможна и 32-, и 64-битная сборка. 32-битную сборку PostgreSQL можно произвести с использованием Visual Studio 2013 — Visual Studio 2022 , а также отдельных выпусков Windows SDK версии с 8.1a по 10. Для 64-битных сборок также можно использовать Microsoft Windows SDK версии с 8.1a по 10 или Visual Studio 2013 и новее. При сборке с Visual Studio 2013 — Visual Studio 2022 поддерживаются системы, начиная с Windows 7 и Windows Server 2008 R2 SP1 .

Инструменты для компиляции с помощью Visual C++ или Platform SDK находятся в каталоге src\tools\msvc . При сборке убедитесь, что в системном пути PATH не подключаются инструменты из набора MinGW или Cygwin . Также убедитесь, что в пути PATH указаны каталоги всех необходимых инструментов Visual C++. Если вы используете Visual Studio , запустите Visual Studio Command Prompt . Если вы хотите собрать 64-битную версию, вы должны выбрать 64-битную версию данной оболочки, и наоборот. Начиная с Visual Studio 2017 , это можно сделать в командной строке, воспользовавшись скриптом VsDevCmd.bat . О его параметрах и их значениях по умолчанию можно узнать, запустив его с ключом -help . Вы можете выбрать целевую архитектуру процессора, тип сборки и целевую ОС в приглашении Visual Studio Command Prompt с помощью скрипта vcvarsall.bat . Например, выполнив vcvarsall.bat x64 10.0.10240.0 , вы подготовитесь к сборке выпускаемой 64-битной версии для Windows 10. О других параметрах vcvarsall.bat можно узнать, запустив его с ключом -help . Все эти скрипты должны запускаться из каталога src\tools\msvc .

До начала сборки можно создать файл config.pl и изменить в нём желаемые параметры конфигурации или пути к сторонним библиотекам, которые будут использоваться. Для получения конфигурации сначала считывается и разбирается файл config_default.pl , а затем применяются все изменения из config.pl . Например, чтобы указать, куда установлен Python , следует добавить в config.pl :

$config-> = 'c:\python310';

Вам нужно задать только те параметры, которые отличаются от заданных в config_default.pl .

Если вам необходимо установить какие-либо другие переменные окружения, создайте файл с именем buildenv.pl и поместите в него требуемые команды. Например, чтобы добавить путь к bison, которого нет в PATH, создайте файл следующего содержания:

$ENV=$ENV . ';c:\some\where\bison\bin';

Передать дополнительные аргументы командной строки команде сборки Visual Studio (msbuild или vcbuild) можно так:

$ENV="/m";

18.1.1. Требования

Для сборки PostgreSQL требуется следующее дополнительное ПО. Укажите каталоги, в которых находятся соответствующие библиотеки, в файле конфигурации config.pl .

Microsoft Windows SDK

Если с вашим инструментарием для разработки не поставляется поддерживаемая версия Microsoft Windows SDK , рекомендуется установить последнюю версию SDK (в настоящее время 10), которую можно загрузить с https://www.microsoft.com/download/.

Устанавливая SDK, вы всегда должны выбирать для установки пункт Windows Headers and Libraries (Заголовочные файлы и библиотеки Windows). Если вы установили Windows SDK , включая Visual C++ Compilers , Visual Studio для сборки вам не нужна. Обратите внимание, что с версии 8.0a в SDK для Windows не включается полное окружение для сборки в командной строке. ActiveState Perl

ActiveState Perl требуется для запуска скриптов, управляющих сборкой. Perl из MinGW или Cygwin работать не будет. ActiveState Perl также должен находиться по пути в PATH. Готовый двоичный пакет можно загрузить с https://www.activestate.com. Заметьте, что требуется версия 5.8.3 или выше, при этом достаточно бесплатного стандартного дистрибутива (Standard Distribution).

Следующее дополнительное ПО не требуется для базовой сборки, но требуется для сборки полного пакета. Укажите каталоги, в которых находятся соответствующие библиотеки, в файле конфигурации config.pl .

ActiveState TCL

Требуется для компиляции PL/Tcl (Заметьте, что требуется версия 8.4 или выше, при этом достаточно бесплатного стандартного дистрибутива (Standard Distribution)). Bison и Flex

Для компиляции из Git требуются Bison и Flex , хотя они не нужны для компиляции из дистрибутивного пакета исходного кода. Bison должен быть версии 1.875 или 2.2, либо новее, а Flex — версии 2.5.31 или новее.

И Bison , и Flex входят в комплект утилит msys , который можно загрузить с http://www.mingw.org/wiki/MSYS в качестве компонента набора MinGW .

Вам потребуется добавить каталог, содержащий flex.exe и bison.exe , в путь, задаваемый переменной PATH, в buildenv.pl , если она его ещё не включает. В случае с MinGW, это будет подкаталог \msys\1.0\bin в каталоге вашей инсталляции MinGW.

Примечание

Bison, поставляемый в составе GnuWin32, может работать некорректно, когда он установлен в каталог с именем, содержащим пробелы, например, C:\Program Files\GnuWin32 (целевой каталог по умолчанию в англоязычной системе). В таком случае, возможно, стоит установить его в C:\GnuWin32 или задать в переменной окружения PATH короткий путь NTFS к GnuWin32 (например, C:\PROGRA~1\GnuWin32 ).

Diff требуется для запуска регрессионных тестов, его можно загрузить с http://gnuwin32.sourceforge.net. Gettext

Gettext требуется для сборки с поддержкой NLS, его можно загрузить с http://gnuwin32.sourceforge.net. Заметьте, что для сборки потребуются и исполняемые файлы, и зависимости, и файлы для разработки. MIT Kerberos

Требуется для поддержки проверки подлинности GSSAPI. MIT Kerberos можно загрузить с https://web.mit.edu/Kerberos/dist/index.html. libxml2 и libxslt

Требуется для поддержки XML. Двоичный пакет можно загрузить с https://zlatkovic.com/pub/libxml, а исходный код с http://xmlsoft.org. Учтите, что для libxml2 требуется iconv, который можно загрузить там же. LZ4

Требуется для поддержки метода сжатия LZ4 . Двоичные файлы и исходный код можно загрузить с https://github.com/lz4/lz4/releases. Zstandard

Требуется для поддержки метода сжатия Zstandard . Двоичные файлы и исходный код можно загрузить с https://github.com/facebook/zstd/releases. OpenSSL

Требуется для поддержки SSL. Двоичные пакеты можно загрузить с https://www.slproweb.com/products/Win32OpenSSL.html, а исходный код с https://www.openssl.org. ossp-uuid

Требуется для поддержки UUID-OSSP (только для contrib). Исходный код можно загрузить с http://www.ossp.org/pkg/lib/uuid/. Python

Требуется для сборки PL/Python . Двоичные пакеты можно загрузить с https://www.python.org. zlib

Требуется для поддержки сжатия в pg_dump и pg_restore . Двоичные пакеты можно загрузить с https://www.zlib.net.

18.1.2. Специальные замечания для 64-битной Windows

PostgreSQL для архитектуры x64 можно собрать только в 64-битной Windows, процессоры Itanium не поддерживаются.

Совместная сборка 32- и 64-битных версий в одном дереве не поддерживается. Система сборки автоматически определит, в каком окружении (32- или 64-битном) она запущена, и соберёт соответствующий вариант PostgreSQL. Поэтому сборку важно запускать в командной оболочке, предоставляющей нужное окружение.

Для использования на стороне сервера сторонних библиотек, таких как Python или OpenSSL , эти библиотеки также должны быть 64-битными. 64-битный сервер не поддерживает загрузку 32-битных библиотек. Некоторые библиотеки сторонних разработчиков, предназначенные для PostgreSQL, могут быть доступны только в 32-битных версиях и в таком случае их нельзя будет использовать с 64-битной версией PostgreSQL.

18.1.3. Сборка

Чтобы собрать весь PostgreSQL в конфигурации выпуска (по умолчанию), запустите команду:

build 

Чтобы собрать весь PostgreSQL в конфигурации отладки, запустите команду:

build DEBUG 

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

build psql build DEBUG psql 

Чтобы сменить конфигурацию по умолчанию на отладочную, поместите в файл buildenv.pl следующую строку:

$ENV="Debug";

Также возможна сборка из графической среды Visual Studio. В этом случае вам нужно запустить в командной строке:

perl mkvcbuild.pl 

и затем открыть в Visual Studio полученный pgsql.sln в корневом каталоге дерева исходных кодов.

18.1.4. Очистка и установка

В большинстве случаев за изменением файлов будет следить автоматическая система отслеживания зависимостей в Visual Studio. Но если изменений было слишком много, может понадобиться очистка установки. Чтобы её выполнить, просто запустите команду clean.bat , которая автоматически очистит все сгенерированные файлы. Вы также можете запустить эту команду с параметром dist , в этом случае она отработает подобно make distclean и удалит также выходные файлы flex/bison.

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

install c:\destination\directory 

Если вы хотите установить только клиентские приложения и интерфейсные библиотеки, выполните команду:

install c:\destination\directory client 

18.1.5. Запуск регрессионных тестов

Чтобы запустить регрессионные тесты, важно сначала собрать все необходимые для них компоненты. Также убедитесь, что в системном пути могут быть найдены все DLL, требуемые для загрузки всех подсистем СУБД (например, DLL Perl и Python для процедурных языков). Если их каталоги в пути поиска отсутствуют, задайте их в файле buildenv.pl . Чтобы запустить тесты, выполните одну из следующих команд в каталоге src\tools\msvc :

vcregress check vcregress installcheck vcregress plcheck vcregress contribcheck vcregress modulescheck vcregress ecpgcheck vcregress isolationcheck vcregress bincheck vcregress recoverycheck 

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

vcregress check serial 

За дополнительными сведениями о регрессионных тестах обратитесь к Главе 33.

Для запуска регрессионных тестов клиентских программ с применением команды vcregress bincheck или тестов восстановления, с применением vcregress recoverycheck , должен быть установлен дополнительный модуль Perl:

На момент написания документации модуль IPC::Run не включается ни в инсталляцию Perl ActiveState, ни в библиотеку ActiveState PPM (Perl Package Manager, Менеджер пакетов Perl). Чтобы установить его, загрузите архив исходного кода IPC-Run-.tar.gz из CPAN, по адресу https://metacpan.org/release/IPC-Run, и распакуйте его. Откройте файл buildenv.pl и добавьте в него переменную PERL5LIB, указывающую на подкаталог lib из извлечённого архива. Например:

$ENV=$ENV . ';c:\IPC-Run-0.94\lib';

Тесты TAP, запускаемые скриптом vcregress , поддерживают переменные окружения PROVE_FLAGS и PROVE_TESTS , в которой автоматически разворачиваются шаблоны имён. Данные переменные можно установить в терминале Windows перед запуском vcregress :

set PROVE_FLAGS=--timer --jobs 2 set PROVE_TESTS=t/020*.pl t/010*.pl

Эти параметры также можно задать в файле buildenv.pl :

$ENV='--timer --jobs 2' $ENV='t/020*.pl t/010*.pl'

Некоторые TAP-тесты зависят от набора внешних команд, при наличии которых могут быть запущены связанные с этими командами тесты. Переопределить эти команды или сбросить их можно в следующих переменных в buildenv.pl :

GZIP_PROGRAM

Команда или путь для запуска программы gzip . По умолчанию — gzip , то есть для поиска этой команды будет использоваться PATH . LZ4

Команда или путь для запуска программы lz4 . По умолчанию — lz4 , то есть для поиска этой команды будет использоваться PATH . TAR

Команда или путь для запуска программы tar . По умолчанию — tar , то есть для поиска этой команды будет использоваться PATH . ZSTD

Команда или путь для запуска программы zstd . По умолчанию — zstd , то есть для поиска этой команды будет использоваться PATH .

Пред.	Наверх	След.
Глава 18. Установка из исходного кода в Windows	Начало	Глава 19. Подготовка к работе и сопровождение сервера

Как узнать компилятор c visual studio

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

# Сейчас мы в каталоге `myapp` с файлом CMakeLists.txt # Создадим каталог `myapp-release` и перейдём в него. mkdir --parents ../myapp-release cd ../myapp-release # Сконфигурируем проект для сборки в Release. # Флаг установит опцию CMAKE_BUILD_TYPE в значение "Release", # интерпретатор cmake считает это переключением на Release конфигурацию. cmake -DCMAKE_BUILD_TYPE=Release ../myapp 

На втором шаге нужно запустить финальный скрипт. Не вызывайте make ! Утилита cmake сделает это сама:

# Просим CMake запустить сборку в каталоге `myapp-release` # Можно добавить флаг `--target mylibrary` для сборки только mylibrary # Можно добавить флаг `--clean-first`, чтобы в начале новой сборки # стирать остатки предыдущей. cmake --build . # Аналогичный способ для GNU/Linux. Его по привычке советуют в сети, хотя # make доступен не всегда, а cmake --build работает на всех платформах. make 

Структура CMakeLists.txt

В начале главного файла CMakeLists.txt ставят метаинформацию о минимальной версии CMake и названии проекта:

# Указывайте последнюю доступную вам версию CMake. cmake_minimum_required(VERSION 3.8) # Синтаксис: project( VERSION LANGUAGES CXX), # теги VERSION и LANGUAGES необязательные. project(libmodel3d) 

Затем следует список инструкций, служащих для вычисления различных переменных, создания целей сборки, подключения проектов из подкаталогов и так далее. Например, подключить дополнительный CMakeLists.txt из подкаталога можно так:

# Простая версия: подключает скрипт по пути /CMakeLists.txt add_subdirectory() # Расширенная версия: дополнительно установит подкаталог сборки подпроекта add_subdirectory( ) 

Целью может стать исполняемый файл, собираемый из исходного кода

# Синтаксис: add_executable( ) # Добавлять `.h` необязательно, но лучше для работы из IDE: # - IDE определит заголовок как часть проекта # - cmake будет отслеживать изменения в заголовке и пересобирать # проект при изменениях. add_executable(pngconverter main.cpp PngReader.h PngReader.cpp) 

Целью также может быть библиотека, статическая или динамическая.

# Синтаксис: add_library( [STATIC|SHARED|INTERFACE] ) # Тип библиотеки (staic или shared) зависит от параметров сборки add_library(libpngutils PngUtils.h PngUtils.cpp) # Тип библиотеки: static add_library(libpngtools STATIC PngTools.h PngTools.cpp) 

Автогенерация проекта для Visual Studio (Windows)

Если используется Visual C++, то путь немного другой: на шаге конфигурирования создаётся проект для Visual Studio, который затем можно собрать из IDE либо так же из командной строки.

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

# Сейчас мы в каталоге `myapp` с файлом CMakeLists.txt # Сгенерируем проект Visual Studio для сборки. mkdir --parents ../myapp-build cd ../myapp-build # Конфигурируем для сборки с Visual Studio 2017, версия тулчейна v140 cmake -G "Visual Studio 2017" 

Если проект был сконфигурирован успешно, то в каталоге ../myapp-build появятся автоматически сгенерированный BUILD_ALL.sln и проекты для Visual Studio. Их можно открыть к IDE, либо собрать из командной строки с помощью cmake. Названия опций говорят сами за себя:

cmake --build . \ --target myapp \ --config Release \ --clean-first 

Зависимости между библиотеками и приложениями

Не используйте директивы include_directories , add_definitions , add_compile_options ! Они меняют глобальные настройки для всех целей, это создаёт проблемы при масштабировании.

• Используйте target_link_libraries для добавления статических и динамических библиотек, от которых зависит цель
• Используйте target_include_directories вместо include_directories для добавления путей поиска заголовков, от которых зависит цель
• Используйте target_compile_definitions вместо add_definitions для добавления макросов, с которыми собирается цель
• Используйте target_compile_options для добавления специфичных флагов компилятора, с которыми собирается цель

# Добавляем цель - статическую библиотеку add_library(mylibrary STATIC \ ColorDialog.h ColorDialog.cpp \ ColorPanel.h ColorPanel.cpp) # ! Осторожно - непереносимый код ! # Добавляем к цели путь поиска заголовков /usr/include/wx-3.0 # Лучше использовать find_package для получения пути к заголовкам. target_include_directories(mylibrary /usr/include/wx-3.0) 

Вы можете выбирать область видимости настройки:

• PUBLIC делает настройку видимой для текущей цели и для всех зависящих от неё целей
• PRIVATE делает настройку видимой только для текущей цели
• INTERFACE делает настройку видимой только для всех зависящих от неё целей

Пример использования областей видимости:

# Каталог include будет добавлен к путям поиска заголовков в текущей цели и во всех зависимых целях target_include_directories(myTarget PUBLIC ./include) # Каталог src будет добавлен к путям поиска заголовков только в текущей цели target_include_directories(myTarget PUBLIC ./src) 

Схема зависимостей условного проекта:

Выбор стандарта и диалекта C++

Для настройки стандарта и флагов языка C++ не добавляйте флаги напрямую!

# ! Устаревший метод - прямое указание флага ! target_compile_options(hello PRIVATE -std=c++11) 

В CMake версии 3.8+ вы можете прямо потребовать включить нужный стандарт:

# Источник: https://cmake.org/cmake/help/latest/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html # Включаем C++ 2017 target_compile_features(myapp cxx_std_17) # Альтернатива: включаем C++ 2014 target_compile_features(myapp cxx_std_14) # Альтернатива: включаем C++ 2011 target_compile_features(myapp cxx_std_11) 

В CMake версии до 3.7 включительно можно использовать set_target_properties (если не работает, то у вас слишком старый CMake):

# Стандарт: C++ 2014, расширения языка от производителя компилятора отключены set_target_properties(myapp PROPERTIES CXX_STANDARD 14 CXX_STANDARD_REQUIRED YES CXX_EXTENSIONS NO ) 

Для разработчиков библиотек есть более тонкий контроль над возможностями языка:

# API библиотеки (т.е. заголовки) требуют лямбда-функций и override, # реализация библиотеки требует ещё и range-based for. target_compile_features(mylibrary PUBLIC cxx_override cxx_lambdas PRIVATE cxx_range_for) 

Функции в CMake

CMake позволяет объявлять функции командами function(name) / endfunction() и макросы командами macro(name) / endmacro() . Предпочитайте функции, а не макросы, т.к. у функций есть своя область видимости переменных, а у макросов — нет.

function(hello_get_something var_name) . # Установить переменную в области видимости вызывающей стороны # можно с помощью тега PARENT_SCOPE set($var_name> $ret> PARENT_SCOPE) endfunction() 

Добавление исходников к цели с target_sources

Лучше добавлять специфичные исходники с помощью target_sources, а не с помощью дополнительных переменных.

add_library(hello hello.cxx) if(WIN32) target_sources(hello PRIVATE system_win.cxx) elseif(UNIX) target_sources(hello PRIVATE system_posix.cxx) else() target_sources(hello PRIVATE system_generic.cxx) endif() 

Интерфейс к утилитам командной строки

# Создать каталог debug-build cmake -E make_directory debug-build # Перейти в каталог debug-build cmake -E chdir debug-build 

Функция find_package

Функция find_package принимает имя библиотеки как аргумент и обращается к CMake, чтобы найти скрипт для настройки переменных данной библиотеки. В итоге при сборке либо возникает ошибка из-за того что пакет не найден, либо добавляются переменные, хранящие пути поиска заголовков, имена библиотек для компоновщика и другие параметры.

Пример подключения Boost, вызывающего встроенный в CMake скрипт FindBoost:

# Весь Boost без указания конкретных компонентов find_package(Boost REQUIRED) # Теперь доступны переменные # - Boost_INCLUDE_DIRS: пути к заголовочным файлам # - Boost_LIBRARY_DIRS: пути к статическим/динамическим библиотекам # - Boost_LIBRARIES: список библиотек для компоновщика # - Boost__LIBRARY: библиотека для компоновки с компонентом библиотек Boost 

Пример подключения библиотеки Bullet с помощью встроенного скрипта FindBullet и компоновки с приложением my_app:

# Вызываем встроенный скрипт FindBullet.cmake find_package(Bullet REQUIRED) # Добавляем пути поиска заголовков к цели my_app target_include_directories(my_app $BULLET_INCLUDE_DIRS>) # Добавляем список библиотек для компоновки с целью my_app target_link_libraries(my_app $BULLET_LIBRARIES>) 

PS-Group

• PS-Group
• sshambir@gmail.com

• ps-group
• image/svg+xml sshambir