Злоупотребление словом "библиотека"

Question

Я вижу много вопросов, как здесь, в SO, так и в других местах, о общие библиотеки в VCS ". То есть, проекты foo и bar оба зависят от libbaz, и спрашивающий задается вопросом, как им импортировать исходный код для libbaz в VCS для каждого проекта.

Мой вопрос: WTF? Если libbaz - это библиотека, то foo не нуждается в ее исходный код вообще. Есть несколько библиотек, которые разумно разработаны использоваться таким образом (например, gnulib), но по большей части foo и bar должен просто ссылаться на библиотеку.

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

Если вы не доверяете API, чтобы оставаться стабильным, то вы не можете слепо В любом случае обновите свою собственную копию исходного кода, так что получится?

Резюмируя вопрос: зачем кому-то хотеть хранить копию библиотека в исходном коде для проекта, а не просто ссылки на эта библиотека и требует его в качестве зависимости?

Если единственный ответ "не хочу зависимости", то почему бы не просто распространяйте копию библиотеки вместе с вашим приложением, но храните их совершенно отдельно?

Answer 1

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

Answer 2

В проекте, над которым я сейчас работаю, у нас есть основной код (который находится в одном проекте Subversion) и множество разных библиотек из разных мест, которые находятся в их собственных модулях Subversion. Решение Visual Studio поддерживает отдельные проекты для каждого из них и в конце связывает их вместе. Если бы мы работали на Unix или подобных ОС, мы бы сделали то же самое.

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

API здесь представляет собой красную сельдь: либо он остается прежним, либо меняется, и если он изменился, нам пришлось бы обновить основной код в любом случае. То же относится и к исходным и двоичным библиотекам (либо мы скомпилируем их с основным проектом, либо нет).