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

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

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

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

Ответ 1

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

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

  • Репо Subversion со всеми пакетами в подпапках. В каждой папке пакета в репо были одинаковые подпапки: 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. У нас было много проблем с версией пакета до и хотелось каким-то образом реализовать все различные пакеты.

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

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

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

Ответ 2

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

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

От codegear

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

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

Ответ 3

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