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

Question

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

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

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

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

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

соображения:

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

Спасибо, заранее, за Ваш отзыв!

Маттиас

---

--- UPDATE ---

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Copy-Compile-Delete

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

\Main 
    \Project1 
    \Project2 
    ... 
    \CommonUnits 

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

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