Загрузка пакетов дизайна Delphi на базе проекта

Есть ли способ выбрать пакеты дизайна на базе проектов?

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

Так есть ли у кого-то подходящее решение для этого? (это беспокоило меня уже много лет)

delphi,

11

Ответов: 3


8 принят

На моей предыдущей работе я написал небольшой инструмент, который поможет нам с пакетами управления версиями. Я действительно должен воссоздать этот инструмент в свое свободное время и сделать его доступным. Инструмент не сложно было написать, так что, возможно, вы можете реализовать что-то подобное себе.

В основном он работал следующим образом:

  • Subversion repo со всеми пакетами в подпапках. В каждой папке пакета в репо были одинаковые подпапки: Lib (для DCU), Source, Help (при необходимости)
  • В корневой папке репо находится инструмент вместе с XML-файлом.
  • Файл XML указывал всю необходимую информацию для каждого пакета: в какую папку содержались файлы DCU, в какую папку содержался источник, какую команду нужно выполнить для справки.
  • Инструмент читает в XML и отображает контрольный список всех доступных пакетов. Установленные пакеты (считанные из реестра BDS) отмечены флажком.
  • Пользователь может выбрать, какие пакеты устанавливать или удалять.
  • Инструмент добавляет / удаляет необходимые ключи в реестре BDS. Он добавляет папку DCU / Lib в путь поиска в среде IDE, добавляет исходную папку в путь просмотра IDE и регистрирует команду справки с помощью специального специалиста IDE (этот эксперт предоставляет расширение для меню справки по умолчанию для запуска помощь для всех установленных пакетов)
  • Инструмент будет даже проверять конфликты и зависимости между пакетами. Например, доступны версии 3 и 4 компонентов Raize, которые не могут одновременно быть активными. Проверка зависимостей была полезна для внутренних компонентов, которые были получены от TurboPower AsyncPro (часть внутренних компонентов использовалась для последовательной связи через AsyncPro)

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

Я реализовал все это, когда компания переезжала из Delphi 5/7 в Delphi 2007. У нас было много проблем с версией пакетов раньше и хотелось каким-то образом реализовать все различные пакеты.

Такой подход дал несколько приятных преимуществ:

  • Когда необходимо было исправить ошибки или были выпущены новые версии сторонних пакетов, одному человеку пришлось внести изменения в подрывную деятельность. Все остальные разработчики могут просто сделать обновление от subversion и иметь последнюю версию без каких-либо проблем.
  • Когда в среду будут добавлены новые пакеты компонентов, одному человеку пришлось бы передать все файлы, изменить список пакетов XML, а затем другие разработчики могли бы выполнить обновление subversion и запустить инструмент, чтобы легко интегрировать пакет.
  • Теперь все сторонние и пользовательские компоненты были легко изменены версиями.
  • Включив DCU (и другие двоичные файлы) в репозиторий subversion, мы обеспечили, чтобы все разработчики использовали одну и ту же скомпилированную версию. Прежде чем стало возможным, что в разных сборниках использовались разные настройки, из-за которых некоторые компоненты ведут себя по-разному.
  • Когда все остальные разработчики, наконец, установили Delphi 2007, их пакеты были настроены менее чем за 10 минут (большую часть времени тратили на загрузку всего из репозитория subversion, сам инструмент мог установить 20 пакетов менее чем за 2 секунды). Раньше, при ручной установке всех пакетов для Delphi5 / 7 для установки все это могло занять до 2 дней.

Это не было просто использовано для некоторых внутренних компонентов, репо также включало некоторые из больших пакетов компонентов: Raize Components, JCL / JVCL (используя их установщик, а не инструмент), DevExpress Quantum Grid 3 и 4, TurboPower AsyncPro


6

Это тоже нелегко. Вы можете сделать это, хотя, используя специальный хакер реестра, и конкретный ярлык bds для каждой конфигурации, в которой вы заинтересованы:

Чтобы использовать, просто создайте новый ярлык и измените командную строку для передачи, например, -rMyAlternateBDSReg. Затем после запуска этого запуска создается запись reg, и они могут настроить этот альтернативный реестр, который они хотят, удаляя пакеты и т. Д., Не беспокоясь о том, чтобы испортить установку по умолчанию.

Из codegear

Если вы настроите конфигурацию для каждого проекта, вы можете запустить соответствующий ярлык для данного проекта. Это не автоматическое, но лучше, чем все время там.

Хорошим побочным эффектом является то, что время загрузки будет улучшено.


0

Мы помещаем исходный код для наших пакетов в исходный элемент управления вместе с пакетным файлом, который их перестраивает. Если в дереве есть изменения для пакетов, мы перестраиваем их. Это не касается установки новых пакетов, но есть замечания по реестру, которые могут позаботиться об этом, поэтому вполне возможно, что мы могли бы включать в себя фрагменты .reg, возможно, для этого.

Дельфы,
Похожие вопросы