Куда помещать third-party libraries в VS
От: b0r3d0m  
Дата: 09.06.17 01:42
Оценка:
сап.

Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?

Я вижу следующие варианты решения данного вопроса, каждый со своими плюсами и минусами:

1. Поместить исходники библиотек в репозиторий проекта.
Плюсы:
+ Полный контроль над доступом ко всем зависимостям.
+ Скорость сборки проекта.
+ Возможность подредактировать исходники библиотек под нужды проекта.
Минусы:
— Увеличение размера репозитория.
— Если несколько проектов в пределах одного репозитория требуют разные версии одной и той же библиотеки, то мы будем вынуждены предоставлять несколько копий данной библиотеки.
— Неясная ситуация с НЕ header-only библиотеками. Кто должен их собирать? Специальный build-скрипт? Или .lib / .dll файлы таких библиотек тоже надо помещать в репозиторий проекта? В таком случае мы столкнёмся с ещё большим увеличением размера репозитория (это всё-таки бинарники, которые, в общем случае, ещё и для разных версий IDE должны быть собраны).

2. Ничего не помещать в репозиторий проекта, а вместо этого написать инструкцию (README.md) на тему того, откуда и как доставать / собирать все необходимые проекту зависимости.
Плюсы:
+ Библиотеки не будут занимать место в репозитории.
Минусы:
— Перед первой сборкой проекта придётся выполнить больше ручных действий.
— Отсутствие контроля над доступом к зависимостям, если речь идёт об упоминании сторонних ресурсов в README.md файле (ресурсы стали недоступны -- проект не собрать).

3. Использовать NuGet.
Плюсы:
+ Удобный процесс сборки. Нажал "Build" -- готово.
+ Библиотеки не будут занимать место в репозитории, решается вопрос с разными версиями библиотек.
Минусы:
— Требуемая библиотека может отсутствовать в "стандартном" NuGet-сервере.
— Отсутствие прямого контроля над зависимостями (частично решается поднятием своего собственного NuGet-сервера).
— По сравнению с вариантом, когда все библиотеки хранятся в репозитории проекта, увеличение скорости сборки (но тут всё зависит от расположения NuGet-сервера и размера используемых библиотек).

Что-то забыл?

Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?
Re: Куда помещать third-party libraries в VS
От: kov_serg Россия  
Дата: 09.06.17 05:37
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

B>сап.


B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?

...
B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?

https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-externals.html
https://www.mercurial-scm.org/wiki/Subrepository
https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial

не подходт?
Re: Куда помещать third-party libraries в VS
От: Лось Чтостряслось СССР  
Дата: 09.06.17 07:34
Оценка:
Здравствуйте, 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
социализм или варварство
Re: Куда помещать third-party libraries в VS
От: Vasiliy2  
Дата: 09.06.17 08:35
Оценка:
Здравствуйте, b0r3d0m, Вы писали:


B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?


Я за nuget с восстановлением пакетов. Нет проблем с возможными ошибками определением путей, если вдруг он задан для библиотеки абсолютным. Как уже сказано — нажал build и проект собрался, не ищешь нигде библиотеки, которые кто-то забыл поменять или обновить (или наоборот). Конечно в этом случае надо поднимать свой нугет сервис. Но это не сложно.

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

Самым плохим вариантом считаю хранение библиотек отдельно. Ситуация — забыли обновить библиотеку или readme будет встречаться довольно часто.

Все это — мое личное мнение, основанное, опять таки, на личном опыте.
Re: Куда помещать third-party libraries в VS
От: Sharov Россия  
Дата: 09.06.17 10:42
Оценка:
Здравствуйте, b0r3d0m, Вы писали:


Минусы 3 варианта компенсируйте плюсами 1.
Кодом людям нужно помогать!
Re: Куда помещать third-party libraries в VS
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 09.06.17 13:09
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

B>сап.

Йо!
B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
Я большой фанат подхода "склонировал, открыл проект, нажал "собрать" — и оно сразу собралось". Так что всегда все зависимости ношу с собой (обычно в папке с красноречивыми названием Dependencies, расположенной на уровне солюшена). Но всегда в этой папке держу текстовый файлик, где описываю, откуда чего взялось (а в случае, если зависимость — это какая-то другая опенсорсная либа, собранная мной, то ещё указываю релевантные ключи сборки).
[КУ] оккупировала армия.
Re: Куда помещать third-party libraries в VS
От: Igore Россия  
Дата: 09.06.17 13:53
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

B>сап.

B>Вечный вопрос -- что делать со сторонними библиотеками, использующимися в проекте, написанном на C++ в Microsoft Visual Studio?
B>Я вижу следующие варианты решения данного вопроса, каждый со своими плюсами и минусами:

B>1. Поместить исходники библиотек в репозиторий проекта.

B>Что-то забыл?
B>Что используется у вас на данный момент в компании, где работаете?
Развитие первого вариант, выделена ветка contrib где хранятся все нужные версии исходников, собираются на отдельных машинах и заливаются в JFrog Artifactory, на рабочее место выкачиваются через ivy, у каждого проекта есть свой файл где описаны какие зависимости каких версий ему нужно выкачать.
Re[2]: Куда помещать third-party libraries в VS
От: IID Россия  
Дата: 09.06.17 14:14
Оценка:
Здравствуйте, koandrew, Вы писали:

k>Так что всегда все зависимости ношу с собой (обычно в папке с красноречивыми названием Dependencies, расположенной на уровне солюшена).


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

k>Но всегда в этой папке держу текстовый файлик, где описываю, откуда чего взялось (а в случае, если зависимость — это какая-то другая опенсорсная либа, собранная мной, то ещё указываю релевантные ключи сборки).


А обновляешь их как ? А то вон даже гугл недавно ухитрился обосраться. Смержив Critical RCE баг спустя почти год после его официального фикса вендором. (Для любознательных: "A-35219737") Хотя казалось бы, посади 1 человечка, пусть мониторит зависимости на предмет security.
kalsarikännit
Re[3]: Куда помещать third-party libraries в VS
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 09.06.17 14:35
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Гугл также любит делать. Только зависимости раскладывает по их собственным репкам, а засасывает автоматизированным скриптом.

Да я тут как-то рассказывал, как я трахался с их скриптами в попытках собрать v8. Там квест был тот ещё.

IID>А обновляешь их как ? А то вон даже гугл недавно ухитрился обосраться. Смержив Critical RCE баг спустя почти год после его официального фикса вендором. (Для любознательных: "A-35219737") Хотя казалось бы, посади 1 человечка, пусть мониторит зависимости на предмет security.

Я исключительно вручную по мере необходимости. Само собой прочитываю release notes для обновлений и решаю, надо оно мне или нет. Потому что слишком часто бывает, что в комплекте с одной новой фичей идёт десяток новых багов.
Раньше делал автоматом, но потом отказался после того, как обновление либы сломало рабочий код в очень неподходящий момент.
[КУ] оккупировала армия.
Re: Куда помещать third-party libraries в VS
От: Ночной Смотрящий Россия  
Дата: 11.06.17 21:10
Оценка:
Здравствуйте, b0r3d0m, Вы писали:

B>3. Использовать NuGet.


Вот этот. Если для С++ доступен нугет, странно предыдущие варианты рассматривать.

B>- Требуемая библиотека может отсутствовать в "стандартном" NuGet-сервере.


Собственные фиды отменили? В TFS искаропки, если нет TFS — есть всякие сторонние, например proget.

B>- Отсутствие прямого контроля над зависимостями


Это какая то загадочная паранойя. У пакетов есть версии, другую версию без твоего ведома тебе никто не подсунет.

B>- По сравнению с вариантом, когда все библиотеки хранятся в репозитории проекта, увеличение скорости сборки


Это минус? Некогда на рсдн писать будет?

B>Что предпочитате вы? Что используется у вас на данный момент в компании, где работаете?


Нугет. Публичные библиотеки в официальном репе, свои — в локальном TFS фиде, куда публикуются автоматично при сборке по каждому коммиту в релизную ветку.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.