Коллеги, а как вы храните информацию о зависимостях в Visual Studio проектах, написанных на C++?
NuGet для C++ есть только в VS2015, на которую у нас портировано не так много проектов, да и далеко не все либы можно в нём найти.
Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя. Даже если не коммитить после этого внесённые изменения в репозиторий, они всё равно будут мельтешить перед глазами, да и вообще как-то не по-пацански получается.
А как поступаете вы? Наверняка ведь есть какое-то более оптимальное решение.
Здравствуйте, b0r3d0m, Вы писали:
B>А как поступаете вы? Наверняка ведь есть какое-то более оптимальное решение.
1. Все внешние зависимости относительно solition'а: $(SolutionDir)..\3rdparty\
2. Отдельное ProjectProperty (*.props) для всех проектов в котором каждый указывает свои локальные настройки, а в систему контроля версий эту props'у не заливать
3. Объединение двух предыдущих пунктов: есть props'а в которой указаны общие пути для внешних зависимостей по относительным путям, при этом каждый разработчик может в одном месте указать свои хотелки по путям (но тогда их уже не заливать, это будет один файл на весь проект).
Здравствуйте, b0r3d0m, Вы писали:
B>NuGet для C++ есть только в VS2015, на которую у нас портировано не так много проектов, да и далеко не все либы можно в нём найти.
Думаю там можно написать пакет вручную для требуемой зависимости, и использовать внутренний репозиторий.
B>Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя. Даже если не коммитить после этого внесённые изменения в репозиторий, они всё равно будут мельтешить перед глазами, да и вообще как-то не по-пацански получается.
Думаю (не уверен потому что напрямую их не использую — потому что CMake) в этих опциях можно использовать переменные окружения. То есть использовать в пути %DEPENDENCY_DIR%/../include, где каждый разработчик сам установит эту переменную.
В CMake переменные окружения работают, но там помимо этого встроена локальная настройка/поиск путей на стадии configure.
B>А как поступаете вы? Наверняка ведь есть какое-то более оптимальное решение.
Зависит от.
Например иногда проще всю зависимость добавить в репозиторий вместе с основным проектом. И обновлять по мере необходимости.
Если брать Linux и подобное — то там пути зависимостей "стандартные".
Можно использовать штуки типа ExternalProject_Add
Здравствуйте, b0r3d0m, Вы писали:
B>Коллеги, а как вы храните информацию о зависимостях в Visual Studio проектах, написанных на C++?
в первую очередь использовать CMake... VS файлы это всего лишь артефакты сборки
B>NuGet для C++ есть только в VS2015, на которую у нас портировано не так много проектов, да и далеко не все либы можно в нём найти.
есть же nuget.exe! 3rd party зависимости лежат в отдельной репе (в ветках), собираются на CI и выкладываются в собственную NuGet репу (она подключена всеми девелоперами в конфигах nuget'a -- пара команд в CLI). установка производится в 1 каталог, выбираемый разработчиком (через конфиг nuget'a). в этом каталоге наши CMake проекты будут шарить finder'ами в поисках зависимостей.
т.е. в конечном итоге, все зависимости это реально внешние пакеты (по отношению к собираемому) и все управление их версиями делается в CMakeLists.txt -- таким образом, легко можно иметь одновременно несколько версий, скажем boost, установленных через nuget, и использовать их в разных проектах, или в разных ветках одного и того же проекта, или... в общем ВОЗМОЖНО ВСЕ %)
B>Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя. Даже если не коммитить после этого внесённые изменения в репозиторий, они всё равно будут мельтешить перед глазами, да и вообще как-то не по-пацански получается.
еще один "непацанский" подход, как уже порекомендовал кое-кто из коллег выше, использовать переменные окружения в файлах проектов... до CMake было в каждом проекте 4-5 студийных solutionа разных версий... добавление 1 файла в проект, уже вызывало ректальную боль... требовало наличия всех поддерживаемых студий у всех разработчиков, практически не реально взять и просто попробовать, а как мы собираемся с новой версией 3rd party библы, требуемые переменные окружения (их зиллиард) слабо документированы (в виках) и представляют проблему при первоначальном развертывании разработческого окружения, ... короче полный содом и гоморра
B>А как поступаете вы? Наверняка ведь есть какое-то более оптимальное решение.
чем скорее начнете движение к CMake, тем больше сэкономите нервов, времени, бюджета...
Здравствуйте, b0r3d0m, Вы писали:
B>Коллеги, а как вы храните информацию о зависимостях в Visual Studio проектах, написанных на C++?
B>NuGet для C++ есть только в VS2015, на которую у нас портировано не так много проектов, да и далеко не все либы можно в нём найти.
Создать пакет NuGet совсем не сложно.
Можно поднять локальный сервер через NuGet Server или ProGet и там держать то, что не должно быть в публичном доступе.
Здравствуйте, b0r3d0m, Вы писали:
B>Коллеги, а как вы храните информацию о зависимостях в Visual Studio проектах, написанных на C++?
Во-первых, проекты, солюшены и проперти вполне можно отдавать в общий доступ.
Единственно, — нужна культура прописывания путей в них. Следить, чтобы студия туда не напихала абсолютных или разработчико-специфичных путей. Но это несложно.
Если солюшены здоровенные, то надо освоить shared properties для того, чтобы не редактировать каждый проект отдельно.
Во-вторых, если есть какие-то уж совсем third party библиотеки, которые каждый разработчик должен класть не в подкаталог солюшена, а в отдельное, своё любимое, место, — для этого существуют переменные окружения.
BOOST_PATH=.....
Один раз договориться, и всё. И в проектах писать пути с подстановкой: ${BOOST_PATH}
В-третьих. Даже если .vcxproj / .sln генерятся из кроссплатформенных проектов типа симейка или гипа, — один чёрт, значит, эти переменные окружения будут упомянуты в проекте симейка.
Здравствуйте, b0r3d0m, Вы писали:
B>Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя. Даже если не коммитить после этого внесённые изменения в репозиторий, они всё равно будут мельтешить перед глазами, да и вообще как-то не по-пацански получается.
B>А как поступаете вы?
мы по-старинке создаем переменные окружения типа BOOST_PATH и уже их прописывем в свойствах проекта. все проекты комитим. каждый разработчик уже на своей тачке как угодно прописывает знаение переменной BOOST_PATH. такой подзод только для буста используем, ибо он толстый
маленькие либы из инета мы комитим (речь об исходниках) и каждый раз пересобираем. пути в свойствах проекта относительные задаем, поэтому сложностей нет
Здравствуйте, b0r3d0m, Вы писали:
T>>Мы, вроде, сносно живём с нюгетом на vs2012. B>А как прикрутили?
Честно говоря, не понимаю, в чём вопрос. Никак особенно не прикручивали: поставили nuget extension в студию (или он уже стоял, а мы только обновили) и начали использовать.
Какие-то пакеты делали сами с помощью CoApp либо напрямую Nuget.exe. Если опишете более конкретно, в чём проблема, постараюсь помочь.
Здравствуйте, b0r3d0m, Вы писали:
B>Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), B>но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя.
Непонятно, как из первого следует второе. Если только каждый будет туда пихать собственные абсолютные пути.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, b0r3d0m, Вы писали:
B>Коллеги, а как вы храните информацию о зависимостях в Visual Studio проектах, написанных на C++?
B>NuGet для C++ есть только в VS2015, на которую у нас портировано не так много проектов, да и далеко не все либы можно в нём найти.
B>Мы по-старинке прописываем пути до заголовочных файлов и либ в свойствах проекта ("Additional Include Directories" и "Additional Library Directories"), но при таком подходе каждому разработчику, скачавшему проект, придётся редактировать указанные опции под себя. Даже если не коммитить после этого внесённые изменения в репозиторий, они всё равно будут мельтешить перед глазами, да и вообще как-то не по-пацански получается.
B>А как поступаете вы? Наверняка ведь есть какое-то более оптимальное решение.
1) Мы применяем для этого переменные среды (например):
OPENCV_DIR = D:\opencv
Если нада что-то подкорректировать — правим Environment Variables.
2) Я все-таки стараюсь, чтобы у меня и у ребят из моей команды, все рабочие проекты были в тех же самых местах (DISK:\Directory\...).
Перекуём баги на фичи!
Честно говоря, не понимаю, в чём вопрос. Никак особенно не прикручивали: поставили nuget extension в студию (или он уже стоял, а мы только обновили) и начали использовать.
