Можно ли установить макрос препроцессора в файл sln, а не в проект?(VS2008 c ++) - PullRequest
Новая
       22

Можно ли установить макрос препроцессора в файл sln, а не в проект?(VS2008 c ++)

4 голосов
/ 23 сентября 2010

Я поддерживаю большую кодовую базу, и некоторые файлы vcproj используются в разных решениях.Из-за некоторых ужасных настроек и зависимостей, кажется, лучший способ решить некоторые проблемы сборки - это #ifdef кода, но для этого мне нужно установить определение препроцессора на уровне файла решения, а не на уровне vcproj.

Это возможно?

Как это сделать?

Ответы [ 6 ]

4 голосов
/ 23 сентября 2010

Я полагаю, что вы, возможно, захотите создать лист свойств проекта с VS Project Manager , от которого могут наследоваться все проекты.Это позволит вам устанавливать любые общие параметры проекта, включая макросы препроцессора, в одном месте и наследовать их по мере необходимости.

4 голосов
/ 23 сентября 2010

Выберите все проекты в вашем решении. Project + Properties, C / C ++, Препроцессор, Определения препроцессора. Добавить 

/DSOLUTION=$(SolutionName)

Теперь вы можете проверить значение макроса SOLUTION в вашем исходном коде.

3 голосов
/ 16 мая 2015

Я наконец-то нашел то, что мне подходит

в моем "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», я получаю список свойств для всего решения, не меняя ничего внутри моих проектов.Это становится новыми функциями для моего Visual Environement

1 голос
/ 15 мая 2015

Другой подход:

Отредактируйте ваш vcxproj (или ваш vcxproj.user) примерно так: 

<PreprocessorDefinitions Condition="'$(SolutionName)'=='NameOfYourSolution'">
    YOUR_DEFINITION;%(PreprocessorDefinitions)
</PreprocessorDefinitions>

он не идеален, так как зависит от вашего имени файла sln.Было бы здорово, если бы вместо этого мы использовали переменную $ (SolutionConfiguration).

К сожалению, я вижу только переменную для конфигурации проекта: $ (Configuration).

В любом случае, это помогает....

1 голос
/ 23 сентября 2010

2008 sln's действительно глупы, у них есть только списки проектов / файлов, которые нужно поместить в обозреватель решений и зависимости проектов, поэтому я не думаю, что это вариант.

Мой инстинкт инстинкта - что-то делать с относительными путями. Например, в вашем stdafx.h вы можете #include ".... \ project_configuration.h", затем для сборки sln a вы будете проверять вещи в одном dir, а sln b в другом. У каждого будет свой отдельный project_configuration.h.

Я полагаю, что вы можете сделать нечто подобное с файлами vsprops, которые, по сути, являются #include для файлов vcproj, хотя я считаю, что их немного раздражает поддерживать со временем.

0 голосов
/ 23 сентября 2010

Ну, я также посмотрел на

Определить значение препроцессора из командной строки, используя MSBuild

и

msbuild, определив УсловныйСимволы компиляции

, и они могут также работать, однако наша система сборки сейчас довольно хрупкая, и я не могу изменить ее все.

Решение, которое я нашелс было клонировать конфигурацию сборки для проекта в решении и дать ему другое имя.Затем я добавил определение макроса / препроцессора в эту новую конфигурацию.

Кажется, работает как нужно.Таким образом, одно решение использует старую конфигурацию «release», а другое решение использует конфигурацию клона «ReleaseSpecial» (не то имя, которое я действительно использовал) с различными определениями препроцессора.

Не идеально, но работает.

Было бы неплохо, если бы с объектами было проще работать, или файлы SLN могли бы передаваться в препроцессоре по умолчанию.

...