Каков наилучший способ поделиться исходными файлами Delphi между проектами?

Ответ 1

Использовать функцию общего доступа к системе управления версиями

• Pro: Быстрая и простая настройка, если система SCM поддерживает ее.
• Pro/Con: каждый потребительский проект может независимо влиять на время компиляции.
• Con: Официального расположения в местной рабочей копии источников нет.
  • Это может привести к путанице.
• Con: Изменения источника не отражаются в других местах до тех пор, пока вы не проверите и не восстановите их.
  • Чтобы правильно проверить другие проекты, перед регистрацией, возможно, но королевская боль в прикладе.
• Con: Не все SCM-системы поддерживают общие файлы.
  • Subversions ближайшей функцией является svn на уровне папки: externals.

(Edit: переименовать это, чтобы избежать путаницы. Конечно, каждый должен использовать Source Control!:-))

Ответ 2

Использовать проект библиотеки

• Pro: только один экземпляр каждого файла, который можно редактировать.
• Pro: только один компилятор для каждого исходного файла.
  • Меньше времени для компиляции.
  • Согласованная компиляция между зависимыми проектами.
  • Естественные инкрементные сборки.
• Pro: Отладчик, естественно, ссылается на правильный источник.
  • TODO: Подтвердите.
• Pro/Con: потребительские проекты не могут независимо влиять на время компиляции.
• Con: Может быть сложно управлять совместным доступом по файловому уровню.
  • TODO: Исследуйте.
• Con: Может потребоваться много усилий для настройки.
  • Настройка проектов MSBuild.
  • Требуемые параметры проекта должны быть централизованы, и эти изменения должны быть проверены.

Ответ 3

Я думаю, никаких специальных решений не требуется. В нашем проекте (несколько приложений, которые используют большие области кода) мы используем следующий подход:

• Разделить исходный код на папки.
• Создание пакетов для логических единиц общего кода.
• Поддержка монолита (без использования пакетов) и разделенных сборок.
• Монолитные сборки используются для кодирования и отладки. Каждое приложение имеет свой собственный каталог вывода Unit, поэтому все они построены независимо.
• Ограничения зависимости выполняются путями поиска проектов.
• Частичная сборка создается автоматически (мы используем сервер CruiseControl и проект MSBuild). Автоматическая сборка очищает все временные папки перед сборкой, поэтому между последовательными сборками нет зависимостей.

В нашем случае мы не смогли контролировать список импортированных файлов. Тем не менее, мы могли бы контролировать список импортированных пакетов в разделенных сборках. Меньшие пакеты означают лучшую детализацию. Если кто-то добавляет зависимость от устройства, расположенного в папке, недоступной в пути поиска, а пакет, содержащий это устройство, не входит в список использования, расстается сборка сбой. Таким образом, для добавления зависимостей требуется явное действие (изменение MSBuild script, которое генерирует файлы CFG для разделенной сборки).

P.S. Мы используем пакеты не для управления зависимостями, а из-за проблем с версиями Windows, отличных от NT, при работе с большими приложениями. Таким образом, контроль зависимостей является побочным эффектом. Частичные сборки рассматриваются как "выпуск", а монолит - как "отладочная" конфигурация. Монолитные приложения используются только для кодирования и отладки. Разработчики работают с монолитными приложениями и вносят свои собственные изменения в конфигурации проекта, такие как добавление информации об отладке VCL, включение и отключение проверки диапазона, оптимизация и т.д. Однако после фиксации SVN CC пытается сделать раздельную сборку. Он игнорирует файлы CFG из репозитория и воссоздает их с помощью специальной задачи проекта MSBuild. Поэтому мы можем быть уверены, что никаких проблем с зависимостями не было (и выполнить другие проверки).

Поскольку нам не нужны монолитные и разделенные сборки одновременно, у нас есть только один проект для каждого приложения. Если вы хотите создать обе версии в MSBuild script, вы можете просто добавить еще одну цель, повторно создать CFG еще раз и указать еще один каталог вывода Unit. Естественно, если обе версии необходимы разработчикам, было бы удобнее иметь больше проектов.

Ответ 4

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

\Main
   \Project1
   \Project2
   ...
   \CommonUnits

Мы добавляем общие единицы к соответствующим проектам (независимо от того, нет ли в той же папке, что и файл проекта). Кроме того, иногда легче использовать условные определения уровня проекта (Project | Options | Directories/Conditionals) для небольших разностей кода. Например, Project1 будет иметь что-то вроде "APP_PROJECT1", и вы можете использовать $IFDEF в общих единицах для записи определенного кода.

Что важно: в этом случае лучше иметь один репозиторий управления версиями для всего пакета (root -\Main, конечно).

Ответ 5

Copy-на-компиляции

• Pro: совместное использование файлов может управляться по файлу.
• Pro/Con: каждый потребительский проект может независимо влиять на время компиляции.
• Con: Отладчик будет ссылаться на временную копию, а не на официальную версию.
  • TODO: Посмотрите, есть ли способ изменить это.
• Con: Может потребоваться некоторая работа по настройке проектов MSBuild.
• Con: Может быть сложно поэтапно создавать общие файлы.
  • Может потребоваться переписать некоторые из правил Delphis MSBuild.

Ответ 6

Copy-Compile-Delete

• Pro: только одна официальная копия каждого файла для редактирования.
• Pro: Отладчик не будет ссылаться на временную копию, так как она была удалена с помощью отладки.
  • TODO: убедитесь, что отладчик найдет исходный источник, если мы поместим его в "Путь просмотра".
• Pro: совместное использование файлов может управляться по файлу.
• Pro/Con: каждый потребительский проект может независимо влиять на время компиляции.
• Con: Может потребоваться некоторая работа по настройке проектов MSBuild.
• Con: Может быть сложно/невозможно инкрементно создавать общие файлы.
  • Может потребоваться переписать некоторые из правил Delphis MSBuild.