Добавить флаг компиляции visual studio
Я хочу написать файл cmake, который устанавливает различные параметры компилятора для clang ++, g ++ и MSVC в сборках отладки и выпуска.
То, что я сейчас делаю, выглядит примерно так:
Но у меня есть пара проблем с этим:
- Во-первых, тривиально: не существует ли такой команды, как appen, которая позволила бы мне заменить set(CMAKE_CXX_FLAGS "$ Foo") с append(CMAKE_CXX_FLAGS "Foo") ?
- Я прочитал несколько раз, что не следует устанавливать вручную CMAKE_CXX_FLAGS и подобные переменные в первую очередь, но я не уверен, какой другой механизм использовать.
- Наиболее важно: как я делаю это здесь, мне нужен отдельный каталог сборки для каждого компилятора и конфигурации. В идеале я хотел бы преобразовать это в несколько объектов в одном каталоге, чтобы я мог, например, вызов make foo_debug_clang ,
Так что мои вопросы
- а) Есть ли лучший способ написать сценарий cmake, который решает мои «болевые точки»?
решение вопросов, упомянутых выше? - б) Есть ли что-то вроде общепринятой современной практики создания таких проектов?
Большинство ссылок, которые я мог найти в Интернете, либо устарели, либо показывают только тривиальные примеры. В настоящее время я использую cmake3.8, но если это что-то меняет, меня еще больше интересует ответ для более свежих версий.
Решение
Ваш подход — как прокомментировал @Tsyvarev — был бы абсолютно нормальным, поскольку ваш запрос на «новый» подход в CMake будет следующим:
Ты взял add_compile_options() и — как @ Al.G. прокомментировал — «используй грязный генератор выражений ».
Есть несколько недостатков выражений генератора:
- Очень полезно $ выражение доступно только в версии CMake> = 3.8
- Вы должны написать это в одну строку. Чтобы избежать этого, я использовал string(APPEND . ) , который вы также можете использовать для «оптимизации» вашего set(CMAKE_CXX_FLAGS "$ . звонки.
- Это трудно читать и понимать. Например. точки с запятой необходимы, чтобы сделать его списком опций компиляции (иначе CMake будет его заключать в кавычки).
Так что лучше использовать более читаемый и обратно совместимый подход с add_compile_options() :
И да, вы больше не указываете явно стандарт C ++, вы просто называете C ++ особенность Ваш код / цель зависит от target_compile_features() звонки.
Для этого примера я выбрал cxx_lambda_init_captures например, старый компилятор GCC выдает следующую ошибку (например, что происходит, если компилятор не поддерживает эту функцию):
И вам нужно написать скрипт-обертку для создания нескольких конфигураций с генератор make-файлов «с одной конфигурацией» или использовать «мультиконфигурация» IDE как Visual Studio.
Вот ссылки на примеры:
Итак, я проверил следующее с Open Folder Поддержка Visual Studio 2017 CMake для объединения в этом примере сл, лязг а также MinGW составители:
CMakeSettings.json
mingw32-make.cmd
Таким образом, вы можете использовать любой генератор CMake из Visual Studio 2017, происходит нездоровое цитирование (например, сентябрь 2017 года, может быть исправлено позже), которое требует mingw32-make.cmd посредник (удаление кавычек).
Другие решения
Другой способ — использовать файлы .rsp.
что может упростить управление множественными и эзотерическими вариантами.
Вы можете использовать target_compile_options () для «добавления» параметров компиляции.
Обращаясь к первым двум пунктам, но не к третьему:
- Я прочитал несколько раз, что не следует вручную устанавливать CMAKE_CXX_FLAGS и подобные переменные в первую очередь, но я не уверен, какой другой механизм использовать.
Команда, которую вы хотите set_property , CMake поддерживает множество свойств — не все, а множество — таким образом, что избавляет вас от необходимости выполнять работу, специфичную для компилятора. Например:
что для некоторых компиляторов приведет к --std=c++17 но для более ранних с --std=c++1z (до завершения C ++ 17). или же:
приведет это -DHELLO -DWORLD для gcc, clang и MSVC, но для странных компиляторов могут использоваться другие ключи.
Неужели нет такой команды, как append, которая позволила бы мне заменить set(CMAKE_CXX_FLAGS "$ Foo") с append(CMAKE_CXX_FLAGS "Foo")?
set_property может использоваться как в режиме установки, так и в режиме добавления (см. примеры выше).
Я не могу сказать, предпочтительнее ли это add_compile_options или же target_compile_features , хоть.
В интегрированной среде разработки все сведения, необходимые для построения проекта, предоставляются в виде свойств. Эти сведения включают в себя имя приложения, расширение (например, DLL, EXE, LIB), параметры компилятора, параметры компоновщика, параметры отладчика, настраиваемые этапы сборки и многие другие компоненты. Как правило, для просмотра и изменения этих свойств используются страницы свойств. для доступа к страницам свойств выберите Project свойствапроекта в главном меню или щелкните правой кнопкой мыши узел проекта в обозреватель решений и выберите пункт свойства.
Свойства по умолчанию
При создании проекта система задает значения для различных свойств. Значения по умолчанию варьируются в зависимости от типа проекта и параметров, выбранных в мастере приложений. Например, проект ATL имеет свойства, связанные с MIDL-файлами, но эти свойства отсутствуют в базовом консольном приложении. В области "Общие" на страницах свойств отображаются свойства по умолчанию:
Применение свойств к конфигурациям сборок и целевым платформам
Некоторые свойства, такие как имя приложения, применяются ко всем вариантам сборки и целевым платформам, будь это сборка отладки или выпуска. Однако большинство свойств зависит от конфигурации. Чтобы создать правильный код, компилятор должен иметь как конкретную платформу, в которой будет выполняться программа, так и конкретные параметры компилятора. Поэтому при задании свойства важно обратить внимание на ту конфигурацию и платформу, к которым должно применяться новое значение. Должен ли он применяться только для отладки сборок Win32 или должен также применяться к отладке ARM64 и отладке x64? Например, для свойства оптимизации по умолчанию задано значение максимизировать скорость (/O2) в конфигурации выпуска, но оно отключено в конфигурации отладки.
Вы всегда можете видеть и изменять конфигурацию и платформу, к которым должно применяться значение свойства. На следующем рисунке показаны страницы свойств с элементами управления конфигурацией и сведениями о платформе в верхней части. Если свойство оптимизации задано здесь, оно будет применяться только для отладки сборок Win32, текущей активной конфигурации, как показано красными стрелками.
На следующем рисунке показана та же страница свойств проекта, но конфигурация изменена на выпуск. Обратите внимание на другое значение для свойства "Оптимизация". Кроме того, обратите внимание, что активной конфигурацией по-прежнему является отладка. Здесь вы можете задать свойства для любой конфигурации, а не только активной.
Целевые платформы
Целевая платформа относится к типу устройства и операционной системы, на которых будет выполняться исполняемый файл. Вы можете создать проект для нескольких платформ. Доступные целевые платформы для проектов C++ зависят от типа проекта. В их число входят только Win32, x64, ARM, ARM64, Android и iOS. Целевая платформа X86, которую вы могли заметить в Configuration Manager, идентична Win32 в собственных проектах C++. Win32 означает 32-разрядную версию Windows, а x64 — 64-разрядную. Дополнительные сведения об этих двух платформах см. в разделе Запуск 32-разрядных приложений.
Дополнительные сведения настройке свойств отладочной сборки см. в следующих разделах:
Параметры компилятора и компоновщика C++
Параметры компилятора и компоновщика C++ находятся в узлах C/C++ и Компоновщик на панели слева в разделе Свойства конфигурации. Эти параметры непосредственно преобразуются в параметры командной строки, которые будут переданы компилятору. Чтобы ознакомиться с документацией по конкретному параметру, выберите параметр в центральной области и нажмите клавишу F1. также можно просмотреть документацию по всем параметрам в MSVC параметры компилятора и параметры компоновщика MSVC.
Значения каталога и пути
MSBuild поддерживает использование констант времени компиляции для определенных строковых значений, таких как включаемые каталоги и пути, называемые макросами. макрос может ссылаться на значение, определенное Visual Studio или системой MSBuild, или на значение, определенное пользователем. Макросы выглядят как $(macro-name) или %(item-macro-name) . Они представлены на страницах свойств, на которых можно ссылаться и изменять их с помощью редактора свойств. Вместо жестко запрограммированных значений, таких как пути к каталогам, используйте макросы. Макросы упрощают совместное использование параметров свойств между компьютерами и версиями Visual Studio. Кроме того, можно обеспечить правильное участие в параметрах проекта в наследовании свойств.
На следующем рисунке показаны страницы свойств для проекта Visual Studio C++. в левой области выбрано правило VC++ каталоги , а на правой панели перечислены свойства, связанные с этим правилом. Значения свойств часто являются макросами, например $(VC_SourcePath) :
Для просмотра значений всех доступных макросов можно использовать Редактор свойств .
Предустановленные макросы
Глобальные макросы:
Глобальные макросы применяются ко всем элементам в конфигурации проекта. Глобальный макрос имеет синтаксис $(name) . Пример глобального макроса — свойство $(VCInstallDir) , которое сохраняет корневой каталог установки Visual Studio. Глобальный макрос соответствует элементу PropertyGroup в MSBuild.
Макросы элементов
Макросы элементов имеют синтаксис %(name) . Для файла макрос элемента применяется только к этому файлу, — например, можно использовать, %(AdditionalIncludeDirectories) чтобы указать каталоги включаемых файлов, которые применяются только к конкретному файлу. Этот тип макроса элемента соответствует метаданным ItemGroup в MSBuild. При использовании в контексте конфигурации проекта макрос элемента применяется ко всем файлам определенного типа. Например, свойство конфигурации определений препроцессора C/C++ может принимать макрос элемента, который применяется ко всем cpp-файлам в проекте. Этот тип макроса элемента соответствует метаданным ItemDefinitionGroup в MSBuild. Дополнительные сведения см. в разделе Определения элементов.
Пользовательские макросы
Вы можете создавать пользовательские макросы для использования в качестве переменных в сборках проекта. Например, можно создать пользовательский макрос, предоставляющий значение пользовательскому шагу сборки или пользовательскому средству сборки. Пользовательский макрос — это пара "имя-значение". Для доступа к этому значению в файле проекта используется нотация $(name) .
Пользовательский макрос хранится на странице свойств. если проект еще не содержит страницу свойств, его можно создать, выполнив действия, описанные в разделе общий доступ или повторное использование Visual Studio параметры проекта.
Создание пользовательского макроса
В левой области диалогового окна выберите Пользовательские макросы. В правой области нажмите кнопку Добавить макрос, чтобы открыть диалоговое окно Добавление пользовательского макроса.
В диалоговом окне задайте имя и значение для макроса. Кроме того, можно установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Редактор свойств
Редактор свойств можно использовать для изменения некоторых строковых свойств и выбора макросов в качестве значений. Чтобы открыть редактор свойств, выберите свойство на странице свойств, а затем нажмите кнопку со стрелкой вниз справа. Если раскрывающийся список содержит Правка >, можно выбрать его, чтобы отобразить редактор свойств для этого свойства.
В редакторе свойств можно нажать кнопку Макросы, чтобы просмотреть доступные макросы и их текущие значения. На следующем рисунке показан редактор свойств для свойства Дополнительные каталоги включаемых файлов после нажатия кнопки Макросы. Если установлен флажок наследовать от родительского объекта или проекта по умолчанию и добавить новое значение, то оно добавляется к любому значению, наследуемому в данный момент. Если снять флажок, новое значение заменяет наследуемые значения. В большинстве случаев следует не снимать этот флажок.
Добавление каталога включения к набору каталогов по умолчанию
При добавлении каталога включения в проект важно не переопределять все каталоги по умолчанию. Правильный способ добавления каталога — добавить новый путь, например " C:\MyNewIncludeDir\ ", а затем добавить $(IncludePath) макрос к значению свойства.
Быстрый просмотр и поиск всех свойств
Без префикса:
поиск только в именах свойств (подстрока без учета регистра).
" / " или " - ":
поиск только в параметрах компилятора (префикс без учета регистра)
v :
поиск только в значениях (подстрока без учета регистра).
Задание переменных среды для сборки
компилятор MSVC (cl.exe) распознает определенные переменные среды, в частности LIB ,, LIBPATH PATH и INCLUDE . при построении с помощью интегрированной среды разработки свойства, заданные на странице свойств каталоги VC++ , используются для задания этих переменных среды. если LIB LIBPATH значения, и INCLUDE уже заданы, например Командная строка разработчика, они заменяются значениями соответствующих свойств MSBuild. затем сборка добавляет значение свойства VC++ каталоги исполняемых каталогов в PATH . Для задания пользовательской переменной среды можно создать пользовательский макрос и затем установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Задание переменных среды для сеанса отладки
В правой области измените параметры проекта Среда или Объединение среды, а затем нажмите кнопку ОК.
Содержание раздела
Совместное или повторное использование параметров проекта Visual Studio
Создание .props файла с настраиваемыми параметрами сборки, которые можно использовать совместно или повторно.
Наследование свойств проекта
Описывает порядок вычисления для .props .targets .vcxproj переменных среды,, файлов и в процессе сборки.
Изменение свойств и целевых объектов без изменения файла проекта
Создание временных параметров сборки без изменения файла проекта.
компилятор командная таблица Visual Studio (VSCT) предоставляет параметры командной строки для обеспечения успешной компиляции VSCT-файлов.
Параметры командной строки
чтобы просмотреть базовую справку VSCT из Visual Studio командного окна, перейдите к папке Visual Studio пакета SDK путь установки\висуалстудиоинтегратион\тулс\бин\ и введите:
Символы-(тире) и/(косая черта) являются допустимой нотацией для указания параметров командной строки.
Ниже приведены допустимые флаги и их значения.
Параметр-L указывает компилятору выбрать группу строк, чтобы создать файл binary. CTO, соответствующий заданному CultureInfo имени языка и региональных параметров. Указанное имя языка и региональных параметров должно соответствовать атрибуту Language одного или нескольких элементов strings в vsct файле. Если у элемента строк нет атрибута языка, он наследуется от содержащего его элемента коммандтабле.
Файл. vsct может содержать несколько строковых элементов, и у каждого из них может быть другой атрибут языка. Глобализация достигается за счет многократного запуска компилятора VSCT и изменения параметра-L для каждого имени языка и региональных параметров.
Если имя языка и региональных параметров, заданное параметром-L, не соответствует атрибуту Language любого элемента Strings, компилятор будет пытаться сопоставить язык, а не регион. Например, если не удается найти "en-US", компилятор попытается использовать "en". В этом случае будет выполнена попытка использовать текущий язык и региональные параметры операционной системы. Это приведет к компиляции первого найденного элемента Strings.
Переключатели-D и-I имеют синтаксис флагов препроцессора Cl.exe C с одинаковыми именами. Для расширения XML- тестов в атрибутах используются определения-D с форматом X = Y Condition . -I включает пути, используемые для разрешения и ссылок на файлы. Дополнительные сведения см. в справочнике по XML-схеме VSCT.
Компилятор VSCT также может декомпилировать ранее созданный двоичный файл. Для этого укажите двоичный файл для . Если двоичный файл был создан компилятором VSCT, его символы уже внедрены и будут выдавать выходные данные с символами в разделе выходных данных. Если двоичный файл был создан компилятором CTC, выходные данные будут содержать фактические идентификаторы GUID и идентификаторы. Если файл *. ctsym, созданный текущими версиями Ctc.exe, находится в той же папке, что и входной двоичный файл, то символы будут загружены из этого файла и использованы для вывода.
In the IDE, all information that's needed to build a project is exposed as properties. This information includes the application name, extension (such as DLL, LIB, EXE), compiler options, linker options, debugger settings, custom build steps, and many other things. Typically, you use property pages to view and modify these properties. To access the property pages, choose Project > project-name Properties from the main menu, or right-click on the project node in Solution Explorer and choose Properties.
Default properties
When you create a project, the system assigns values for various properties. The defaults vary somewhat depending on the kind of project and what options you choose in the app wizard. For example, an ATL project has properties related to MIDL files, but these properties are absent in a basic console application. The default properties are shown in the General pane in the Property Pages:
Applying properties to build configurations and target platforms
Some properties, such as the application name, apply to all build variations and target platforms, whether it's a debug or release build. But most properties are configuration-dependent. To generate the correct code, the compiler has to know both the specific platform the program will run on and which specific compiler options to use. So when you set a property, it's important to pay attention to which configuration and platform the new value should apply to. Should it apply only to Debug Win32 builds, or should it also apply to Debug ARM64 and Debug x64? For example, the Optimization property, by default, is set to Maximize Speed (/O2) in a Release configuration, but it's disabled in the Debug configuration.
You can always see and change the configuration and platform a property value should apply to. The following illustration shows the property pages with the configuration and platform information controls at the top. When the Optimization property is set here, it will apply only to Debug Win32 builds, the currently active configuration, as shown by the red arrows.
The following illustration shows the same project property page, but the configuration has been changed to Release. Note the different value for the Optimization property. Also note that the active configuration is still Debug. You can set properties for any configuration here; it doesn't have to be the active one.
Target platforms
Target platform refers to the kind of device and operating system that the executable will run on. You can build a project for more than one platform. The available target platforms for C++ projects depend on the kind of project. They include but aren't limited to Win32, x64, ARM, ARM64, Android, and iOS. The x86 target platform that you might see in Configuration Manager is identical to Win32 in native C++ projects. Win32 means 32-bit Windows and x64 means 64-bit Windows. For more information about these two platforms, see Running 32-bit applications.
For more information about setting properties for a Debug build, see:
C++ compiler and linker options
C++ compiler and linker options are located under the C/C++ and Linker nodes in the left pane under Configuration Properties. These options translate directly to command-line options that will be passed to the compiler. To read documentation about a specific option, select the option in the center pane and press F1. Or, you can browse documentation for all the options at MSVC compiler options and MSVC linker options.
The Property Pages dialog box shows only the property pages that are relevant to the current project. For example, if the project doesn't have an .idl file, the MIDL property page isn't displayed. For more information about the settings on each property page, see Property Pages (C++).
Directory and path values
MSBuild supports the use of compile-time constants for certain string values, such as include directories and paths, called macros. A macro can refer to a value that's defined by Visual Studio or the MSBuild system, or to a user-defined value. Macros look like $(macro-name) or %(item-macro-name) . They're exposed in the property pages, where you can refer to and modify them by using the Property Editor. Use macros instead of hard-coded values such as directory paths. Macros make it easier to share property settings between machines and between versions of Visual Studio. And, you can better ensure that your project settings participate correctly in property inheritance.
The following illustration shows the property pages for a Visual Studio C++ project. In the left pane, the VC++ Directories rule is selected, and the right pane lists the properties that are associated with that rule. The property values are often macros, such as $(VC_SourcePath) :
You can use the Property Editor to view the values of all available macros.
Predefined macros
Global macros:
Global macros apply to all items in a project configuration. A global macro has the syntax $(name) . An example of a global macro is $(VCInstallDir) , which stores the root directory of your Visual Studio installation. A global macro corresponds to a PropertyGroup in MSBuild.
Item macros
Item macros have the syntax %(name) . For a file, an item macro applies only to that file—for example, you can use %(AdditionalIncludeDirectories) to specify include directories that apply only to a particular file. This kind of item macro corresponds to an ItemGroup metadata in MSBuild. When it's used in the context of a project configuration, an item macro applies to all files of a certain type. For example, the C/C++ Preprocessor Definitions configuration property can take a %(PreprocessorDefinitions) item macro that applies to all .cpp files in the project. This kind of item macro corresponds to an ItemDefinitionGroup metadata in MSBuild. For more information, see Item Definitions.
User-defined macros
You can create user-defined macros to use as variables in project builds. For example, you could create a user-defined macro that provides a value to a custom build step or a custom build tool. A user-defined macro is a name/value pair. In a project file, use the $(name) notation to access the value.
A user-defined macro is stored in a property sheet. If your project doesn't already contain a property sheet, you can create one by following the steps under Share or reuse Visual Studio project settings.
To create a user-defined macro
In the left pane of the dialog box, select User Macros. In the right pane, choose the Add Macro button to open the Add User Macro dialog box.
In the dialog box, specify a name and value for the macro. Optionally, select the Set this macro as an environment variable in the build environment check box.
Property Editor
You can use the Property Editor to modify certain string properties and select macros as values. To access the Property Editor, select a property on a property page and then choose the down arrow button on the right. If the drop-down list contains , then you can choose it to display the Property Editor for that property.
In the Property Editor, you can choose the Macros button to view the available macros and their current values. The following illustration shows the Property Editor for the Additional Include Directories property after the Macros button was chosen. When the Inherit from parent or project defaults check box is selected and you add a new value, it's appended to any values that are currently being inherited. If you clear the check box, your new value replaces the inherited values. In most cases, leave the check box selected.
Add an include directory to the set of default directories
When you add an include directory to a project, it's important not to override all the default directories. The correct way to add a directory is to append the new path, for example " C:\MyNewIncludeDir\ ", and then to Append the $(IncludePath) macro to the property value.
Quickly browse and search all properties
The All Options property page (under the Configuration Properties > C/C++ node in the Property Pages dialog box) provides a quick way to browse and search the properties that are available in the current context. It has a special search box and a simple syntax to help you filter results:
No prefix:
Search in property names only (case-insensitive substring).
' / ' or ' - ':
Search only in compiler switches (case-insensitive prefix)
v :
Search only in values (case-insensitive substring).
Set environment variables for a build
The MSVC compiler (cl.exe) recognizes certain environment variables, specifically LIB , LIBPATH , PATH , and INCLUDE . When you build with the IDE, the properties that are set in the VC++ Directories Property Page are used to set those environment variables. If LIB , LIBPATH , and INCLUDE values have already been set, for example by a Developer Command Prompt, they're replaced with the values of the corresponding MSBuild properties. The build then prepends the value of the VC++ Directories executable directories property to PATH . You can set a user-defined environment variable by creating a user-defined macro and then checking the box that says Set this macro as an environment variable in the build environment.
Set environment variables for a debugging session
In the left pane of the project's Property Pages dialog box, expand Configuration Properties and then select Debugging.
In the right pane, modify the Environment or Merge Environment project settings and then choose the OK button.
In this section
Share or reuse Visual Studio project settings
How to create a .props file with custom build settings that can be shared or reused.
Project property inheritance
Describes the order of evaluation for the .props , .targets , .vcxproj files, and environment variables in the build process.
Modify properties and targets without changing the project file
How to create temporary build settings without having to modify a project file.
Чтобы собрать инструментальные средства, мне нужно перейти на использование компилятора DevPartner (nmcl.exe).
Кроме того, мне нужно добавить настройки компилятора в существующий CXX_FLAGS для инструментовки.
Как мне это сделать?
Решение
Для версий VS 2008 и более ранних версий …. (кроме VS6 он использует msdev)
Хорошо копаясь больше в cmake, я скажу, что кто-то с большим знанием сможет взять это и бежать с этим.
Я обнаружил, что команды CL и LINK действительно ничего не делают, так как это только запускает Devenv для VS2003 до 2008 и MSBuild для VS2010. Изменение CL на NMCL не будет иметь значения, так как MSBuild использует целевые файлы, поэтому мой другой ответ требует изменения пользовательских файлов. И почему нам нужно использовать другой инструмент здесь.
Devenv, вызванный с / Build, внутренне использует файлы проекта, чтобы знать, какие исходные файлы нужно собрать. Затем он вызовет createprocess для внутреннего вызова CL и LINK по мере необходимости. Вот почему замена CL на NMCL в файлах cmake бесполезна.
К счастью, у нас есть еще один инструмент, который можно использовать здесь ….
Нам нужно изменить
// сделать программу
CMAKE_MAKE_PROGRAM: FILEPATH = C: / Программные файлы (x86) / Общие файлы / Микрофокус / NMShared / CTI / 11.1 / NMdevenv.EXE
в C: / Программные файлы (x86) / Общие файлы / Micro Focus / NMShared / CTI / 11.1 / NMdevenv.EXE
Теперь это место, где нужен кто-то, имеющий немного больше знаний. Нам также нужно передать тип инструментовки в nmdevenv в качестве 1-х параметров.
Я верю, что это можно сделать примерно так
набор (CMAKE_MAKE_PROGRAM «$ » / nmon «)
Еще одна проблема заключается в том, что нам нужен devenv, чтобы быть в пути, поэтому переменная Path env также должна быть установлена правильно. Это можно сделать, запустив правильный файл vscvars bat.
Надеюсь, что это поможет, и если вы используете vs2008 и предыдущие версии, добавьте шаги, необходимые для того, что я начал здесь. Я уверен, что это поможет другим пользователям в долгосрочной перспективе. Если у меня будет больше времени для расследования, я найду способ сделать это.
редактировать
Ну, мне удалось заставить это работать с VS2008. Мне пришлось внести изменения в нашу оболочку nmdevenv, так как cmake уничтожил нашу функциональность SearchPath.
Вот что я сделал.
Заменили программу make, как указано выше
Побежал VCVars32
Запустил cmake — построить mytestproj
Запустил программу под BounsChecker
Теперь я переключился на / nmtxon для профилирования производительности
Это поставило меня в тупик, так как он продолжал компилироваться для обнаружения ошибок
И именно тогда я нашел это в преобразованных файлах проекта
и все хорошо. У меня была опция скомпилированного исполнения.
Поэтому я вернулся и изменил эту строку в файле CMakeCache.txt, открыл графический интерфейс, настроил, сгенерировал
// Флаги, используемые компилятором во всех типах сборки.
CMAKE_CXX_FLAGS: STRING = / NMbcon / DWIN32 / D_WINDOWS / W3 / Zm1000 / EHsc / GR
Затем проект снова переключился на использование / NMbcon. Так что это правильное место для переключения, если вы хотите скомпилировать все с нами. В противном случае используйте соответствующую строку Debug или release.
часть вывода Cmake
Извещение о приборе на выходе
Используйте Cmake для генерации CMakeCache.txt и каталогов
Изменить CmakeCahe
Используйте NMDevenv в качестве программы MAKE
Добавить / NMon переключатель на флаги
запустить CmakeGui и сгенерировать снова
Запустите VCVars32
Запустите файл cmake —build
Запустите программу под devpartner
Другие решения
Какую версию Visual Studio вы используете? Это имеет большое значение, так как управление инструментами изменилось за эти годы. , , не столько по версии DevPartner, сколько по версии Visual Studio.
Не уверен на 100% для файла cmake, но это из старого make-файла VS 6, модифицированного для Devpartner. Возможно, вы можете опубликовать соответствующий раздел make-файла, чтобы я мог на него посмотреть.
/ nmbcon — это флаг компиляции, который говорит, что использование BC инструментовки / nmtxon будет использоваться для анализа покрытия
CPP_PROJ = / nologo / MD / W3 / Gm / GX / Zi / Od / D «WIN32» / D «NDEBUG» / D «_WINDOWS» / D «_WINDLL» / D «_AFXDLL» / D «_MBCS» / D «_AFXEXT «/Fp»$(INTDIR)\main.pch» /Yu»stdafx.h «/ Fo» $ (INTDIR) \ «/Fd»..\bin\Debug\MAIN.pdb» / FD / GZ / c
CPP_PROJ = / nmbcon / nologo / MD / W3 / Gm / GX / Zi / Od / D «WIN32» / D «NDEBUG» / D «_WINDOWS» / D «_WINDLL» / D «_AFXDLL» / D «_MBCS» / D «_AFXEXT» /Fp»$(INTDIR)\main.pch «/Yu»stdafx.h» / Fo «$ (INTDIR) \» /Fd»..\bin\Debug\MAIN.pdb «/ FD / GZ / с
Да, и другой постер — это правильные вещи, которые сильно изменились в зависимости от версии Visual Studio. VS2010 изменил процесс сборки для использования MSBuild, поэтому мы полностью изменили способ перехвата и установки для VS2010 и 2012.
*РЕДАКТИРОВАТЬ
Ну, я сделал скачать и пройти через боль Cmake стажировки сегодня утром. Для VS2010 это, кажется, довольно простая модификация, точно такая же, как и для одного из наших пользователей, использующих MSBuild из командной строки.
Это может быть повторяющимся разделом для каждого
что вы хотите построить.
Следующий ключ DevPartner_IsInstrumented говорит нам инструменту (1) или нет (0).
Последний ключ DevPartner_Instrumented_Type> указывает, какой тип был передан Instrumetnt / nmbcon (Boundschecker) / nmtxon (Performance или Coverage) или оба ключа переданы.
Так это может выглядеть
это будет Boundschecker для отладки win32, ничего для выпуска win32, ничего для отладки x64 и Performance / Coverage для выпуска x64
Если IsInstrumented 0, все, что находится в типе, не будет иметь значения, так как оно не будет передано.
Если не использовать VS2010, моя заметка ниже может быть правильной для этих версий.
Для полного раскрытия я являюсь ведущим разработчиком по инструментальному движку для DevPartner.
Читайте также: