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

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

Уточнение: мы хотим использовать один исходный файл в нескольких проектах Delphi. Мы использовали наш инструмент SCM для размещения одного и того же файла в нескольких папках, но это не очень элегантный опыт, и мы также рассматриваем возможность переноса на инструмент, который не поддерживает это.

Как я исследовал этот вопрос, я рассмотрел несколько разных подходов, но мне нравится знать, что вы делаете и как вы находите свой подход.

Важные сценарии:

  • Код времени
    • Для добавления новой зависимости для обмена должно потребоваться явное объявление, чтобы управление совместным использованием.
    • Добавление новой зависимости совместного использования должно быть относительно простым; он не должен требовать сложного процесса.
      • Хорошим будет один файл, в котором перечислены все "импортированные" файлы проектов (извне).
  • Compile времени
    • Все проекты всегда должны строиться с одной текущей версией (текущей как из состояния синхронизации источника, так и с локальными изменениями).
      • (Поддержание различных версий в разных местах должно использовать разветвление файлов, которое не является темой здесь.)
    • Возможно ли, что каждый проект может повлиять на компиляцию общих файлов с различными настройками компилятора (включая флаги).
      • Его возможно легче поддерживать (то есть долгосрочный) исходный код, который всегда строится последовательно.
      • Возможно, легче сделать исправления для технического обслуживания (т.е. краткосрочные), если объем указанных изменений можно легко ограничить одним проектом.
  • Debug времени
    • Правильная версия источника должна автоматически открываться при входе в процедуру или установке точки останова.
    • Редактирование отображаемого источника должно повлиять на следующую сборку.
      • Мы не хотим отлаживать временную копию источника: мы, вероятно, потеряем код в замешательстве.

Вопросы:

  • Near-Term:
    • Какой подход будет проще всего внедрить?
  • Long-Term:
    • Какой подход будет проще всего использовать и поддерживать?

Спасибо, за ваш отзыв!

Маттиас

<ч/" > --- ОБНОВЛЕНИЕ ---

Спасибо за отзыв, ответы, комментарии и голоса!

Я начал путь поместить общие файлы в один проект "производитель" и импортировал список скомпилированных файлов в каждый "потребительский" проект. Проекты связаны с MSBuild. Когда вещи будут больше прибиты, я отредактирую этот вопрос и ответ "Библиотечный проект", чтобы поделиться тем, что я узнал.

Оставайтесь с нами! (Но не задерживайте дыхание, вы будете утомлять в течение нескольких минут!: P)

ОТВЕТЫ

Ответ 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.