Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
Я вижу следующие варианты решения данного вопроса, каждый со своими плюсами и минусами:
1. Поместить исходники библиотек в репозиторий проекта.
Плюсы:
+ Полный контроль над доступом ко всем зависимостям.
+ Скорость сборки проекта.
+ Возможность подредактировать исходники библиотек под нужды проекта.
Минусы:
— Увеличение размера репозитория.
— Если несколько проектов в пределах одного репозитория требуют разные версии одной и той же библиотеки, то мы будем вынуждены предоставлять несколько копий данной библиотеки.
— Неясная ситуация с НЕ header-only библиотеками. Кто должен их собирать? Специальный build-скрипт? Или .lib / .dll файлы таких библиотек тоже надо помещать в репозиторий проекта? В таком случае мы столкнёмся с ещё большим увеличением размера репозитория (это всё-таки бинарники, которые, в общем случае, ещё и для разных версий IDE должны быть собраны).
2. Ничего не помещать в репозиторий проекта, а вместо этого написать инструкцию (README.md) на тему того, откуда и как доставать / собирать все необходимые проекту зависимости.
Плюсы:
+ Библиотеки не будут занимать место в репозитории.
Минусы:
— Перед первой сборкой проекта придётся выполнить больше ручных действий.
— Отсутствие контроля над доступом к зависимостям, если речь идёт об упоминании сторонних ресурсов в README.md файле (ресурсы стали недоступны -- проект не собрать).
3. Использовать NuGet.
Плюсы:
+ Удобный процесс сборки. Нажал "Build" -- готово.
+ Библиотеки не будут занимать место в репозитории, решается вопрос с разными версиями библиотек.
Минусы:
— Требуемая библиотека может отсутствовать в "стандартном" NuGet-сервере.
— Отсутствие прямого контроля над зависимостями (частично решается поднятием своего собственного NuGet-сервера).
— По сравнению с вариантом, когда все библиотеки хранятся в репозитории проекта, увеличение скорости сборки (но тут всё зависит от расположения NuGet-сервера и размера используемых библиотек).
Что-то забыл?
Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?
Здравствуйте, b0r3d0m, Вы писали:
B>сап.
B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
... B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?
Здравствуйте, b0r3d0m, Вы писали:
B>сап.
B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
B>Я вижу следующие варианты решения данного вопроса, каждый со своими плюсами и минусами:
B>1. Поместить исходники библиотек в репозиторий проекта.
я за B>Плюсы: B>+ Полный контроль над доступом ко всем зависимостям. B>+ Скорость сборки проекта. B>+ Возможность подредактировать исходники библиотек под нужды проекта. B>Минусы: B>- Увеличение размера репозитория. B>- Если несколько проектов в пределах одного репозитория требуют разные версии одной и той же библиотеки, то мы будем вынуждены предоставлять несколько копий данной библиотеки. B>- Неясная ситуация с НЕ header-only библиотеками. Кто должен их собирать? Специальный build-скрипт? Или .lib / .dll файлы таких библиотек тоже надо помещать в репозиторий проекта? В таком случае мы столкнёмся с ещё большим увеличением размера репозитория (это всё-таки бинарники, которые, в общем случае, ещё и для разных версий IDE должны быть собраны).
а почему размер репозитория так важен?
B>2. Ничего не помещать в репозиторий проекта, а вместо этого написать инструкцию (README.md) на тему того, откуда и как доставать / собирать все необходимые проекту зависимости. B>Плюсы: B>+ Библиотеки не будут занимать место в репозитории. B>Минусы: B>- Перед первой сборкой проекта придётся выполнить больше ручных действий.
это просто ужасно!
в идеале проект после чекаута должен собираться единичным нажатием кнопки build
B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?
Я за nuget с восстановлением пакетов. Нет проблем с возможными ошибками определением путей, если вдруг он задан для библиотеки абсолютным. Как уже сказано — нажал build и проект собрался, не ищешь нигде библиотеки, которые кто-то забыл поменять или обновить (или наоборот). Конечно в этом случае надо поднимать свой нугет сервис. Но это не сложно.
Если нет возможности использовать нугет, то следующим по предпочтению вариантом — хранить в репозитории. Здесь возможна проблема привязки абсолютных путей к библиотекам, но вероятность потери библиотеки меньше. Проблему с поеданием места проблемой не считаю.
Самым плохим вариантом считаю хранение библиотек отдельно. Ситуация — забыли обновить библиотеку или readme будет встречаться довольно часто.
Все это — мое личное мнение, основанное, опять таки, на личном опыте.
Здравствуйте, b0r3d0m, Вы писали:
B>сап.
Йо! B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
Я большой фанат подхода "склонировал, открыл проект, нажал "собрать" — и оно сразу собралось". Так что всегда все зависимости ношу с собой (обычно в папке с красноречивыми названием Dependencies, расположенной на уровне солюшена). Но всегда в этой папке держу текстовый файлик, где описываю, откуда чего взялось (а в случае, если зависимость — это какая-то другая опенсорсная либа, собранная мной, то ещё указываю релевантные ключи сборки).
Здравствуйте, b0r3d0m, Вы писали:
B>сап. B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio? B>Я вижу следующие варианты решения данного вопроса, каждый со своими плюсами и минусами:
B>1. Поместить исходники библиотек в репозиторий проекта. B>Что-то забыл? B>Что используется у вас на данный момент в компании, где работаете?
Развитие первого вариант, выделена ветка contrib где хранятся все нужные версии исходников, собираются на отдельных машинах и заливаются в JFrog Artifactory, на рабочее место выкачиваются через ivy, у каждого проекта есть свой файл где описаны какие зависимости каких версий ему нужно выкачать.
Здравствуйте, koandrew, Вы писали:
k>Так что всегда все зависимости ношу с собой (обычно в папке с красноречивыми названием Dependencies, расположенной на уровне солюшена).
Гугл также любит делать. Только зависимости раскладывает по их собственным репкам, а засасывает автоматизированным скриптом.
k>Но всегда в этой папке держу текстовый файлик, где описываю, откуда чего взялось (а в случае, если зависимость — это какая-то другая опенсорсная либа, собранная мной, то ещё указываю релевантные ключи сборки).
А обновляешь их как ? А то вон даже гугл недавно ухитрился обосраться. Смержив Critical RCE баг спустя почти год после его официального фикса вендором. (Для любознательных: "A-35219737") Хотя казалось бы, посади 1 человечка, пусть мониторит зависимости на предмет security.
Здравствуйте, IID, Вы писали:
IID>Гугл также любит делать. Только зависимости раскладывает по их собственным репкам, а засасывает автоматизированным скриптом.
Да я тут как-то рассказывал, как я трахался с их скриптами в попытках собрать v8. Там квест был тот ещё.
IID>А обновляешь их как ? А то вон даже гугл недавно ухитрился обосраться. Смержив Critical RCE баг спустя почти год после его официального фикса вендором. (Для любознательных: "A-35219737") Хотя казалось бы, посади 1 человечка, пусть мониторит зависимости на предмет security.
Я исключительно вручную по мере необходимости. Само собой прочитываю release notes для обновлений и решаю, надо оно мне или нет. Потому что слишком часто бывает, что в комплекте с одной новой фичей идёт десяток новых багов.
Раньше делал автоматом, но потом отказался после того, как обновление либы сломало рабочий код в очень неподходящий момент.
Здравствуйте, b0r3d0m, Вы писали:
B>3. Использовать NuGet.
Вот этот. Если для С++ доступен нугет, странно предыдущие варианты рассматривать.
B>- Требуемая библиотека может отсутствовать в "стандартном" NuGet-сервере.
Собственные фиды отменили? В TFS искаропки, если нет TFS — есть всякие сторонние, например proget.
B>- Отсутствие прямого контроля над зависимостями
Это какая то загадочная паранойя. У пакетов есть версии, другую версию без твоего ведома тебе никто не подсунет.
B>- По сравнению с вариантом, когда все библиотеки хранятся в репозитории проекта, увеличение скорости сборки
Это минус? Некогда на рсдн писать будет?
B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?
Нугет. Публичные библиотеки в официальном репе, свои — в локальном TFS фиде, куда публикуются автоматично при сборке по каждому коммиту в релизную ветку.