Я всегда использовал Visual Studios, встроенную в поддержку графического интерфейса пользователя, для настройки своих проектов, часто используя таблицы свойств, чтобы несколько проектов использовали общий набор.
Один из моих основных В связи с этим возникает проблема управления несколькими проектами, конфигурациями и платформами. Если вы просто делаете все с помощью основного графического интерфейса пользователя (щелкните правой кнопкой мыши проект -> свойства), он быстро становится беспорядочным, сложным в обслуживании и подверженным ошибкам (например, невозможность правильно определить какой-либо макрос или использование неправильной библиотеки времени выполнения и т. Д.). Имея дело с тем, что разные люди помещают туда библиотеки зависимостей в разных местах (например, мои все живут в "C: \ Libs \ [C, C ++] \ [lib-name] \" если только есть некоторые с интеграцией VS2010, которые могут отслеживать такие изменения.
Я только что обнаружил то, что, по моему мнению, было невозможным (это не отображается в графическом интерфейсе пользователя), что помогает сделать список свойств гораздо более полезным. Атрибут "Condition" многих тегов в файлах свойств проекта, а также его можно использовать в файлах .props!
Я просто собрал следующее в качестве теста, и он отлично сработал и выполнил задачу из 5 (общих, x64, x86, отладка, выпуск) отдельных листов свойств!
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="UserMacros">
<!--debug suffix-->
<DebugSuffix Condition="'$(Configuration)'=='Debug'">-d</DebugSuffix>
<DebugSuffix Condition="'$(Configuration)'!='Debug'"></DebugSuffix>
<!--platform-->
<ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform>
<ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform>
<!--toolset-->
<Toolset Condition="'$(PlatformToolset)' == 'v90'">vc90</Toolset>
<Toolset Condition="'$(PlatformToolset)' == 'v100'">vc100</Toolset>
</PropertyGroup>
<!--target-->
<PropertyGroup>
<TargetName>$(ProjectName)-$(Toolset)-$(ShortPlatform)$(DebugSuffix)</TargetName>
</PropertyGroup>
</Project>
Единственная проблема заключается в том, что графический интерфейс свойств не может справиться с этим, проект, который использует приведенную выше таблицу свойств, просто сообщает о унаследованных значениях по умолчанию, таких как «$ (ProjectName)» для цели.
Что касается выходной библиотеки, вы можете выбрать все свои проекты, затем открыть страницы свойств, выбрать Все конфигурации , Все платформы, а затем установите целевое имя на:
$ (ProjectName) - $ (PlatformToolset) - $ (PlatformShortName) - $ (Configuration)
, что даст результат вроде mylib-v100-x86-Debug. lib
Мы делаем что-то подобное и для дополнительных библиотечных каталогов, используя $ (PlatformName)
и # (Configuration)
, чтобы выбрать правильные пути к библиотекам, хотя это означают возня с начальной настройкой библиотек.например, у нас есть boost установить свои библиотеки в boost / lib.Win32
или boost / lib.x64
.
Что касается библиотек и людей, устанавливающих их в разных местах, есть несколько вариантов. Если у вас очень надежная система управления версиями, вы можете просто поместить все в систему управления версиями, живя в папке libs рядом с исходным кодом. Это, вероятно, не сработает, если вы используете больше, чем несколько библиотек, или если они особенно велики.
Другой вариант, который приходит на ум, - установить переменную среды на каждом пользовательском компьютере, которая указывает на корень папки с их библиотеками, например LIB_ROOT = c: \ libraries
, и тогда вы сможете получить к ней доступ в Visual Studio как $ (LIB_ROOT)
.