Я поддерживаю большую кодовую базу, и некоторые файлы vcproj используются в разных решениях. Из-за ужасной конфигурации и зависимостей кажется, что лучший способ справиться с некоторыми проблемами сборки - это #ifdef кода, но для этого мне нужно установить определение препроцессора на уровне файла решения, а не на уровне vcproj.
Это возможно?
Как это сделать?
Я считаю, что вы можете создать лист свойств проекта с помощью VS Project Manager, от которого могут быть унаследованы все проекты. Это позволит вам установить любые общие настройки проекта, включая макросы препроцессора, в одном месте и наследовать их по мере необходимости.
Выберите все проекты в вашем решении. Проект + Свойства, C / C ++, Препроцессор, Определения препроцессора. Добавлять
/DSOLUTION=$(SolutionName)
Теперь вы можете протестировать значение макроса SOLUTION в исходном коде.
Я наконец нашел то, что мне подходит
в моем "C: \ Users \\ AppData \ Local \ Microsoft \ MSBuild \ v4.0"
Немного меняю на:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(SolutionDir)\$(SolutionName).props" Condition="Exists('$(SolutionDir)\$(SolutionName).props')"/>
</Project>
Итак, теперь, если «mysolution.props» находится рядом с «mysolution.sln», я получаю список свойств для всего решения, ничего не меняя внутри моих проектов. Это становится новой функцией для моей визуальной среды.
Import элементов в каждый файл проекта в решении, в котором вы хотите это сделать, было бы безопаснее, поскольку это продолжит работать, если вы переносите решение между системами (или наборами инструментов MSBuild). Например, если ваша машина умирает, вы переустанавливаете ОС, хотите работать над кодом на нескольких машинах (или версиях ОС) или хотите сотрудничать с другим разработчиком.
- person SamB; 02.12.2015
SLN 2008 года действительно тупые, у них есть только списки проектов / файлов, которые нужно добавить в обозреватель решений, и зависимости проектов, поэтому я не думаю, что это вариант.
Мой инстинкт подсказывает мне делать что-то относительными путями. Например, в вашем stdafx.h вы можете #include ".... \ project_configuration.h", затем для построения sln a вы должны проверять все в одном каталоге, а sln b в другом. У каждого будет свой отдельный project_configuration.h.
Я считаю, что вы могли бы сделать что-то подобное с файлами vsprops, которые, по сути, являются #includes для файлов vcproj, хотя я нашел их немного раздражающими для поддержки с течением времени.
Другой подход:
Отредактируйте свой vcxproj (или ваш vcxproj.user) примерно так
<PreprocessorDefinitions Condition="'$(SolutionName)'=='NameOfYourSolution'">
YOUR_DEFINITION;%(PreprocessorDefinitions)
</PreprocessorDefinitions>
это не идеально, так как это зависит от вашего файла sln. Было бы здорово, если бы вместо этого мы использовали переменную $ (SolutionConfiguration).
К сожалению, я вижу только переменную для конфигурации проекта: $ (Configuration).
В любом случае, это своеобразный трюк ...
Ну я тоже посмотрел на
Определите значение препроцессора из командной строки с помощью MSBuild
и
msbuild, определение символов условной компиляции
и они могут работать, однако наша система сборки сейчас довольно хрупкая, и я не в состоянии все это изменить.
Решение, которое я придумал, заключалось в том, чтобы клонировать конфигурацию сборки для проекта в решение и дать ему другое имя. Затем я добавил в эту новую конфигурацию определение макроса / препроцессора.
Похоже, что он работает по желанию. Таким образом, одно решение использует старую конфигурацию "release", а другое решение использует конфигурацию клона "ReleaseSpecial" (не то имя, которое я действительно использовал) с различными defs препроцессора.
Не идеально, но работает.
Было бы неплохо, если бы со свойствами было проще иметь дело или файлы SLN можно было бы передавать в определениях препроцессора.
