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

Question

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

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

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

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

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

Вопросы:

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

Заранее спасибо за отзыв!

Маттиас

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

\Main
   \Project1
   \Project2
   ...
   \CommonUnits

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

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

Answer 4

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

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

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

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

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

Answer 5

Copy-Compile-Delete

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

Answer 6

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

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