Я пытаюсь настроить проект С++ с помощью cmake. Я хочу иметь возможность скомпилировать свой проект как в режиме выпуска, так и в режиме отладки, поэтому мне нужны разные папки для моих исполняемых файлов. Поскольку между этими двумя сборками есть лишь несколько различий, например, флаги компилятора, я бы хотел, чтобы у них было как можно больше общих конфигураций. В идеале моя структура папок должна выглядеть так:
root/
│
├── src/
│
├── CMakeLists
│
└── build/
└── bin/
│ ├── Debug/
│ └── Release/
└──Makefile
В этом случае обе папки используют общие файлы конфигурации makefile и cmake. Я заметил, что визуальная студия делает это примерно так. Однако cmake, кажется, заставляет меня выбирать между режимом отладки и выпуска уже во время работы cmake -B build -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release
. Кажется, я не влияю ни на что cmake --build build --config Release
, например, при настройке каталога двоичного вывода.
В этом посте о переполнении стека предлагается выполнять отладку и выпуск непосредственно во время сборки, а также иметь два совершенно отдельных файла makefile и конфигурации cmake для двух режимов. Это усложнило бы и сделало бы остальную часть моей среды довольно запутанной.
Например, подобные действия всегда будут иметь значение false, даже если --config Release
:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/$<IF:$<CONFIG:Debug>,Debug,Release>)
Есть какие-нибудь указания о том, как добиться этой структуры папок и правильно реализовать режимы сборки для С++ с помощью cmake?
Похоже, вы описываете эффект от использования генератора с одной конфигурацией, такого как «Unix Makefiles» или «Ninja». С помощью «Мульти-генератора Ninja» или генератора «VS» вы получаете то, что описываете: единый каталог сборки с разными каталогами для выпуска, отладки и т. д.
Я изучал конфигурацию ninja-multi и думаю, что это достойное решение проблемы. Лично я предпочел Makefiles, который, похоже, не поддерживает несколько конфигураций.
cmake не является системой сборки Visual Studio.
Я думаю, что обратное тому, что вы говорите, было бы правдой: смешивание разных сборок в одной попытке сборки делает все ужасно сложным, поскольку это потребует переписывания множества относительных путей, особенно с сгенерированными целями, в вашем инструменте выбора сборки " Make-файлы».
Cmake просто не работает таким образом: тип сборки является константой всей конфигурации для Makefiles, Ninja и большинства других серверных программ (исключением является создание проекта Visual Studio).
В одной сборке не может быть двух разных типов сборки. Итак, то, что вы хотите, просто невозможно без выполнения двух запусков cmake, двух запусков сборки и копирования файлов в единую иерархию. В этот момент вы действительно ничего не выиграли!
В этом случае обе папки используют общие файлы конфигурации makefile и cmake.
Точно нет! Makefile обязательно будут разными — будут различаться не только флаги компилятора, но и другие артефакты сборки. Здесь очень мало что можно использовать повторно.
Итак, да, другой источник верен: создайте два разных каталога, два разных запуска cmake
, один с -DCMAKE_BUILD_TYPE=Release
, другой с -DCMAKE_BUILD_TYPE=RelWithDebInfo
(или любой другой тип отладки, который вы хотите).
«Тип сборки является константой всей конфигурации» — это не всегда так. От генератора CMake зависит, известен ли тип сборки на этапе конфигурации или его можно выбрать при сборке проекта. Например. для любого из генераторов на основе Makefile тип сборки известен на этапе конфигурации. Но для генераторов на основе Visual Studio проект настраивается один раз для всех типов сборки, а тип сборки выбирается при сборке проекта.
@Цыварев да, правда, мне следовало указать, что «для выбранного типа сборки Makefiles…» Исправлено.
«создание проекта Visual Studio является исключением» — Visual Studio — не единственный генератор с несколькими конфигурациями. Есть генератор XCode и даже генератор Ninja Multi-Config, который настраивает один раз для нескольких типов сборки. Я бы не сказал, что многоконфигурационные генераторы являются исключением. Кроме того, язык Makefile определенно не является ограничением для написания одного Makefile для разных типов сборки. Мультиконфигурационный генератор на основе Makefile отсутствует... просто потому, что его никто не реализовал.
Пожалуйста, не используйте фрагменты кода JavaScript для кода, отличного от JS.