Как обрабатывать и включать заголовки и библиотеки для построения решения Visual Studio 2010 на разных компьютерах

Question

У меня есть решение Visual Studio 2010, которое должно включать 4 разные сторонние библиотеки и заголовки.Эти сторонние зависимости устанавливаются отдельно перед включением.Таким образом, пути включения для заголовков и библиотек различны на разных машинах.

Теперь я хочу, чтобы мое решение было построено разными разработчиками на разных машинах, чтобы зависимости, включенные в путь этих инструментов, включали с минимальными затратами труда и более плавно.

Iстолкнулись со следующими решениями:

1. Использование переменных среды (Как создать переменные среды в качестве инструкций препроцессора, прежде чем пути этих инструментов будут правильно заданы перед использованием этих переменных среды)

2. Использование страниц свойств (Как мне добавить путь этих инструментов в качестве макросов и сделать доступным на каждой машине, на которой он построен, при условии, что эти инструменты были настроены до построения моего решения)

Любые другие решения ???

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

РЕДАКТИРОВАТЬ: я использую библиотеку Boost, OpenSSL и два других специальных инструмента сторонних производителей, которые очень сильно зависят от версии для моего решения.

У нас есть разные исходные ветви, использующие разные версии библиотекЯ упомянул выше.Также у нас есть другие решения, которые разделяют библиотеки и заголовки.Поэтому не имеет смысла копировать эти библиотеки в каждый каталог решений, так как они являются избыточными.

Таким образом, чтобы они были ОДНЫМ ОБЩИМ местом и связывали их в разных проектах / решениях и из разных путей установки / расположенияэти библиотеки - моя конечная цель.

Answer 1

Я бы предложил использовать файлы свойств (* .vsprops) для нужного вам направления.

Похоже, ваши разработчики сами установили инструменты на свои машины там, где им нравится, поэтому они должны иметь возможность создать файл vsprops для каждого , но хранить в стандартном месте. Ваш VS Файлы проекта должны будут включать все эти файлы vsprops. Это означает, что ваш источник контроля эффективно ссылается на четыре файла вне контроля версий.

Конечно, в конечном итоге вы должны либо заставить своих разработчиков устанавливать сторонние инструменты в тех же местах на своих компьютерах (это можно делать постепенно, по мере появления новых версий этих инструментов), либо включать заголовочные файлы и файлы библиотек для инструменты управления исходным кодом.

Answer 2

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

Второе утверждение не следует из первого;почему они обязательно находятся по разным путям?

Использование переменных среды (Как создать переменные среды в качестве инструкций препроцессора, прежде чем пути этих инструментов будут правильно заданы перед использованием этих переменных среды)

VC ++ позволяет определять любое количество действий перед сборкой.Вы можете либо напрямую установить переменную окружения с помощью команды set, либо вызвать пакетный файл с командой set.Последнее может быть предпочтительнее, поскольку тогда все разработчики имеют общий файл проекта, и им нужно только изменить командный файл в соответствии со своей средой, и, конечно, командный файл может иметь любое количество команд.

Любая другаярешение (я) ???

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

Обратите внимание, что они не должны находиться в подпапке проекта, но этобезопаснее, если, например, у вас есть несколько проектов (или разные ревизии или ветви одного и того же проекта), использующие разные версии внешних библиотек, извлеченные одновременно.

Answer 3

Другим решением было бы использование символических ссылок, поэтому, с точки зрения проекта, похоже, что машина имеет ту же структуру каталогов, что и другие машины.Хотя на самом деле не рекомендую делать это, он может быстро запутаться, и, если вы положите все на C, вы облажались, если у одного из разработчиков есть машина без диска C.

Еще одно решение -пытаясь гарантировать, что каждая отдельная машина использует ту же самую структуру каталогов, например, храня все необходимое для сборки в репозитории.Это может быть несколько ограничивающим, особенно если ваши проекты используют абсолютные пути к этим каталогам.

Второе решение, которое вы даете, на самом деле довольно хорошее, если не самое лучшее.Типичное использование - это добавить что-то вроде workspace.props.template в дерево исходных текстов, которое должно быть переименовано в workspace.props и изменено пользователем (или с помощью автоматического инструмента/ Пакетный скрипт / ...) для включения правильных путей.Мы используем это все время, и это очень удобно.Он также позволяет легко настраивать различные независимые деревья сборки на одном и том же компьютере, поскольку в лист свойств входят только абсолютные пути.

Answer 4

У нас похожая ситуация на работе, и это боль в заднице.В настоящее время мы переносим все сторонние библиотеки и заголовки в подпапку 3-го участника в наш репозиторий - таким образом, они всегда находятся в одном и том же месте, и все строят против одной и той же версии, и если вам нужно построить старую ветку, то вы будетеПолучить правильные версии библиотеки автоматически при переходе на филиал.Я думаю, что это лучший способ сделать это - все остальное вызывает головную боль.