Организация проектных зависимостей

Question

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

Проблема в том, что многие люди имеют более одной версии одной и той же библиотеки (например, пользователи проекта повышают 1,36, а я использую повышение 1,39 для некоторых других моих вещей), и каждый разработчик имеет их в разных местах (например, я используйте C: \ lib \ c ++ \ boost_1_36).

В результате прямо сейчас все разработчики должны добавить довольно большое количество записей для каждого проекта «Дополнительные каталоги включения» и «Дополнительные каталоги библиотеки», что является проблемой, особенно при попытке настроить новых участников. правильно (например, убедитесь, что правильные статические / динамические зависимости связаны для каждой конфигурации, что усугубляется большинством библиотек, использующих общее имя для всех файлов .lib и .dll, а не как, например, boost делает это с именем файла) отражая конфигурацию и автоматическое связывание).

Я думал об использовании макросов в свойствах проекта, с такими вещами, как "$ (MYSQL_HOME) \ lib \ opt" в "Дополнительных включаемых каталогах", однако я не вижу способа определить свои собственные ( как MYSQL_HOME))

Answer 1

Вы можете использовать листы свойств , чтобы помочь управлять зависимостями и другими общими настройками проекта. Листы свойств также позволяют вам определять определяемые пользователем макросы , что необходимо для определения собственных макросов, таких как MYSQL_HOME

Answer 2

Некоторые люди могут предложить дополнение «Среда компоновки решений». Я бы порекомендовал вам НЕ использовать это - используйте списки свойств, как говорит Джеймс. Причины, по которым следует избегать Solution Build Environment:

1. Он не работает с пакетными сборками - он использует среду из текущей конфигурации для сборки всего пакета, что приведет к неправильным флагам компилятора / компоновщика и трудно отслеживаемым ошибкам сборки (поскольку при сборке одной конфигурации время от времени проблема не обнаруживается).
2. Вызывает стороннюю зависимость от ваших пользователей. Кто-то должен установить это дополнение для сборки с вашими проектами.
3. Это зависит от решения, а не от проекта. Это означает, что кто-то другой может вносить ваши проекты в качестве зависимостей, но не будет автоматически вводить все параметры среды, в которых нуждаются ваши проекты.
4. Трудно отследить, откуда берутся настройки. Списки свойств интегрированы в графический интерфейс, и их довольно легко просматривать. Файлы .slnenv, с другой стороны, не имеют интеграции IDE, и поэтому будет труднее отслеживать изменения.
5. В листах свойств можно указать столько специфических настроек, что фактические настройки в любом данном файле .vcproj будут пустыми. Я определяю все свои настройки в листах свойств, и тогда отдельным проектам нужно только определить, какие листы свойств они наследуют. Поскольку Solution Build Environment определяет только переменные среды («макросы», как их называет MS), файлы проекта по-прежнему будут загромождены настройками, даже если все они просто ссылаются на эти переменные среды. Это беспорядок.