Используя управляемые библиотеки источника в источнике управлял проектами
У меня есть несколько проектов, которые создают допускающие повторное использование библиотеки. Все эти проекты являются объектом управления исходным кодом.
Когда я пользуюсь этими библиотеками в проекте, я просто связываю с тем же версию на своем локальном диске. Однако как можно предположить, это может вызвать проблемы, когда я фиксирую назад, и другой разработчик пытается клонировать репозиторий.
Какова лучшая практика при использовании компонентов также при управлении исходным кодом? Я должен включать "проекты библиотеки" в "основной проект" управление исходным кодом? Это вызовет проблемы?
NB: библиотеки берет довольно много директив компилятора так его почти невозможный просто скомпилировать статическую версию и ссылку на это. Плюс я все еще разрабатываю их параллельно.
3 ответа
У вас есть два основных типа зависимостей:
- исходные зависимости (вам необходимо включить в исходные тексты вашего проекта источник из другого проекта),
- двоичные зависимости (вам нужно включить упакованный набор файлов, подобных тем, которые находятся в общей библиотеке).
Если, когда вы говорите «Я использую эти библиотеки в проекте», вы имеете в виду, что вам нужны двоичные файлы для компиляции вашего проекта, тогда вы можете сохранить указанные двоичные файлы во внешнем репозитории (т. Е.не (D) VCS, как Mercurial, а репозиторий артефактов, например Nexus )
Но если вы имеете в виду, что вам нужно включать исходные коды, потому что вы также делаете некоторые изменения в этих библиотеках, используя их для разработки ваш проект, то Mercurial subrepos лучше подходят.
По моему собственному опыту, поддержка совместимости с библиотеками, которые вы пишете одновременно, значительно улучшается за счет использования карт экспорта для предоставления нескольких версий ваших интерфейсов клиентским программам. Лучшее руководство, которое я знаю, - это Ульрих Дреппер http://people.redhat.com/drepper/dsohowto.pdf
Если библиотеки находятся под вашим контролем исходных текстов, жизнь должна быть легкой. Я обычно делаю то же самое, что и для разных версий сторонних библиотек: Заведите разные папки для разных версий.
Структура папок сторонних библиотек выглядит следующим образом:
- General
- Delphi
- Components
- LibX
- LibX 9.2.1.3890
- LibX 10.1.0.7151
- LibY
- LibY 3.6
- LibY 5.1
- Plugins
Каждый проект определяет свои зависимости от конкретных версий каждой библиотеки. Возврат к старой версии проекта, таким образом, также возвращает зависимость к старым версиям библиотеки (библиотек).
Теперь с библиотеками сторонних разработчиков у вас обычно нет такого количества различных версий, как с вашими собственными библиотеками, но те же принципы применимы. И чтобы помочь в "текущей разработке" - когда у вас еще нет номера конкретной версии, вы можете просто иметь "головную" версию. Затем, когда вы "выпустите" версию вашей библиотеки, просто добавьте папку этой версии и измените определения проектов, которые до сих пор использовали "голову" из-за параллельной разработки, чтобы они зависели от нового номера версии...