Использование библиотек с контролируемым источником в проектах с контролируемым источником

Question

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

Когда я использую эти библиотеки в проекте, я просто ссылаюсь на одну и ту же ОДНУЮ версию на своем локальном диске. Однако, как вы можете себе представить, это может вызвать проблемы, когда я вернусь, а другой разработчик пытается клонировать репозиторий.

Какова наилучшая практика при использовании компонентов также под управлением источника? Должен ли я включать «библиотечные проекты» в исходный контроль «основного проекта»? Это вызовет проблемы?

NB: Библиотеки принимают множество директив-компиляторов, поэтому практически невозможно просто скомпилировать статическую версию и ссылку на нее. Плюс я все еще разрабатываю их параллельно.

Answer 1

У вас есть два основных вида зависимостей:

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

Если вы говорите: «Я использую эти библиотеки в проекте», вы имеете в виду, что вам нужны двоичные файлы для компиляции вашего проекта, тогда вы можете хранить указанные двоичные файлы во внешнем репозитории (т. Е. Не (D) VCS как ртутные, но artifact repository like Nexus)

Но если вы имеете в виду вы должны включать в себя источники, потому что вы также сделать некоторые эволюции для этих библиотек, используя их для разработки проекта, то Mercurial subrepos является более подходящим.

Answer 2

В моем собственном опыте поддержка совместимости с библиотеками, которые вы пишете одновременно, значительно улучшена за счет использования экспортных карт для предоставления нескольким версиям ваших интерфейсов клиентским программам. Лучший гид я знаю Ульрих Drepper-х http://people.redhat.com/drepper/dsohowto.pdf

Answer 3

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

Структура папок третьей библиотеки стороны выглядит следующим образом:

- General 
    - Delphi 
    - Components 
     - LibX 
     - LibX 9.2.1.3890 
     - LibX 10.1.0.7151 
     - LibY 
     - LibY 3.6 
     - LibY 5.1 
    - Plugins 

каждый проект определяет его зависимость от конкретных версий каждой библиотеки. Возвращаясь к старой версии проекта, таким образом, также возвращается зависимость от более старых версий библиотеки (ов).

Теперь у сторонних библиотек, как правило, не так много разных версий, как вы можете делать со своими собственными библиотеками, но применяются те же принципы. И чтобы помочь в «текущем развитии» - где у вас пока нет определенного номера версии, вы можете просто иметь «головную» версию. Затем, когда вы «выпускаете» версию своей библиотеки, просто добавьте папку этой версии и настройте определения проекта, которые до тех пор, пока не будут известны «голова» из-за параллельной разработки, чтобы зависеть от номера новой версии ...