2010-01-07 3 views
2

Предположим, у вас есть несколько сделанных на заказ проектов на C++ в отдельных хранилищах или каталогах верхнего уровня в том же репозитории. Возможно, 10 - это библиотечные проекты для таких вещей, как графика, база данных, математика и т. Д., А 2 - реальные приложения, использующие эти библиотеки.Организация .libs в кодовой базе нескольких проектов на C++

Каков наилучший способ организовать эти 2 прикладных проекта, чтобы они были нужны .libs?

  • Каждый Lib проект создает .lib в своем собственном каталоге, разработчики должны скопировать их через к области приложения вручную и убедитесь, чтобы получить правильную версию
  • прикладные проекты ожидают Lib проектов, которые будут, в частности, путей и искать .libs в этих местах
  • каталог общий/ЛИЭС используется всеми проектами
  • что-то еще

Это сосредоточено на C++, но я думаю, что это довольно си аналогичные другим языкам, например, организация JAR в проекте Java.

ответ

1

Я бы предложил такой подход:

Организуйте свой код в корневой папке. Назовем его кодом.

Теперь разместите ваши проекты и библиотеки в виде подпапок (например, проектов и библиотек).

Создайте свои библиотеки как обычно и добавьте шаг после сборки, который скопирует полученные заголовки и .lib-файлы в набор общих папок. Например, библиотеки \ include и библиотеки \ lib. Рекомендуется использовать подпапки или соглашение об именах (myLib.lib, myLib_d.lib), чтобы различать различные сборки (например, debug и release), чтобы любая ссылка lib явно предназначалась для одного файла, который никогда не может быть замешан. Это отстой, когда вы случайно связываетесь с неправильным вариантом lib!

Вы также можете скопировать сторонние библиотеки, которые вы используете в этих папках.

Примечание. Чтобы они были организованы, включите ваши файлы с #include "Math \ Utils.h", а не только "Utils.h". И поместите заголовки для всей библиотеки Math в include \ Math, вместо того, чтобы бросать их все в корень папки include. Таким образом, вы можете иметь много библиотек без конфликтов имен. Он также позволяет вам иметь разные версии библиотек (например, Photoshop 7, Photoshop 8), что позволяет вам мультиконфигурировать ваш код в разных средах исполнения.

Затем настроить свои проекты для ссылки на библиотеках в одном из двух способов:

1) Скажите ваш IDE/компилятор, где ЛИЭС использует свою глобальную LIB/включают пути. Это означает, что вы устанавливаете IDE один раз на каждом ПК и никогда не должны указывать, где находятся библиотеки для любых проектов.

2) Или, чтобы каждый проект ссылался на библиотеки с собственными путями lib/include. Это дает вам больше гибкости и позволяет избежать необходимости настраивать каждый ПК, но означает, что вы должны устанавливать одинаковые пути в каждом новом проекте.

(который лучше всего зависит от количества проектов по сравнению с количеством ПК разработчика)

И самая важная часть: Когда вы ссылаетесь на включает/ЛИЭС, используйте относительные пути. например из проектов \ WebApp \ WebApp.proj, используйте ".. \ ..\ Libraries \ include ", а не" C: \ Code \ Libraries \ Include ". Это позволит другим разработчикам и вашему серверу создавать исходный код в другом месте (D: \ MyWork вместо C: \ Code). Не делайте этого, он укусит вас однажды, когда вы найдете разработчика без достаточного дискового пространства на C: \ или если вы хотите разветвить ваш источник управления.

+0

* «Когда вы ссылаетесь на include/libs, используйте относительные paths "* ... предпочитают помещать' ../../ Libraries/Include' в проекты, включая каталоги, а не ссылаться на заголовки явно. Это позволяет избежать нарушения кода, если вы решите переместить его. –

+0

Что происходит, когда AppX использует версия HEAD DatabaseUtils, но AppY не работает против какой-либо версии позже, чем r1234 того же проекта? Ваше решение работает нормально, когда я хочу сказать boost1.2.3 и boost1.2.4 как отдельные проекты - они выпускают их вот так. часто uti проект lity все еще находится в разработке, и новые изменения нарушают функциональность старых приложений. –

+0

@gf: Я имел в виду, что ./../Libraries/Include находится в вашем INCLUDE_PATH, но ваш #include будет использовать подпапки для разных libs, т. Е. #include "Math \ Utils.h". В противном случае вам нужно поставить миллион заголовков в одну папку, и в итоге у вас будет много файлов с именами конфликтов (например, «types.h» используется в каждой библиотеке для разных вещей) –