Пользовательская зависимость компонента hell

Question

Я пытаюсь создать пакет для пользовательского компонента, который я создал. Он основан на нескольких библиотеках, включая Graphics32, GraphicEx и CCR.Exif.

Я создал проект пакет, написал блок, включая его процедуру регистра, добавлены некоторые дополнительные ссылки Delphi уведомил меня о к требует секции (включая dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg. dcp, xmlrtl.dcp и dclGraphicEx140.dcp), и добавлено много блоков в , содержит раздел, чтобы избежать предупреждений о том, что это происходит неявно. Проект компилируется и может быть установлен и использован на моей машине без проблем. Однако, когда я хочу установить его на другую машину, проблемы начинаются. В конце концов, мне пришлось копировать все DCU со всех сторонних компонентов, которые я использовал, плюс DCP и BPL из GraphicEx, которые мне пришлось установить даже.

Поставка большого количества файлов является обломком, но непреодолимым, но для установки других пакетов также нет необходимости. Я мог избавиться от этого DCP и BPL, добавив еще больше блоков в , содержащий раздел, но это привело к появлению сообщений об ошибках на моей собственной машине, на которой фактически установлен GraphicEx. Это меня смущает, потому что с Graphics32 ничего подобного не происходит ...

Во всяком случае, как мне сохранить минимальное распределение и избежать таких ситуаций? Я хочу, чтобы другие разработчики в моей команде могли использовать пакет, не беспокоясь о том, что я использовал для его создания. Для начала, не могут ли все сторонние подразделения быть скомпилированы в мое собственное DCU?

Answer 1

Резюме

Не использовать Delphi на некоторое время, но, действительно развивать свои собственные визуальные элементы (последняя версию я работа была Delphi 6).

При обработке зависимостей пакетов существует 2 проблемы. Один из них устанавливается в среде Delphi, создавая элементы управления в палитре компонентов, а также редакторы компонентов &.

И еще при раздаче скомпилированных пакетов в машины клиентов.

Это также зависит от того, в какой версии на Delphi вы работаете.

Design Time

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

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

Существует путь к текстовому поле для файлов «.dcp», другой для « .dcu» и т. Д.

Если у вас есть визуальные элементы управления и такие как редакторы свойств или редакторы компонентов, лучше разбить код на 2 пакета («Время выполнения» & «Время разработки»).

Обычно я размещаю проекты delphi (пакеты) вне папки установки delphi.

Run Time

Обычно быстрый способ поставить "* .bpl" "файлы в Windows (32)/системной папке, или подобные "" .DCP папку DLL" окна.

---

Пакеты структура папок исходного кода внушение

Управление пакетами может быть затруднено. Я не знаю, как изменился процесс установки с помощью Embarcadero и более поздних версий Delphi. Следующая диаграмма - пример того, как организовать исходный код. Надеюсь, поможет.

[-]--+--c: 
.....| 
.....+--[-]--+--software 
.............| 
.............+--[+]-----java 
.............| 
.............+--[+]-----php 
.............| 
.............+--[-]--+--delphi (not the delphi folder in program files) 
.....................| 
.....................+--[+]-----apps (source code for delphi programs) 
.....................| 
.....................+--[+]-----other 
.....................| 
.....................+--[-]--+--packages (all delphi packages source code here) 
.............................| 
.............................+--[+]-----lib (a single package for non visual controls, libraries) 
.............................| 
.............................+--[+]-----tools (package pair for non visual tcomponent descendants) 
.............................| 
.............................+--[+]-----json (example) 
.............................| 
.............................+--[+]-----xml (example) 
.............................| 
.............................+--[-]--+--mycontrols (folder custom visual controls) 
.............................|.......| 
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder) 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols") 
.............................|................ 
.............................+--[-]-----etc... 

---

Приветствия.

Answer 2

Thijs, вы просто не можете сделать это только с пакетом. Для целевого разработчика потребуется почти все, что вы добавили в пакет. Но есть альтернативный способ сделать то, что вы хотите: создать DLL со всеми компонентами/библиотеками, которые вы используете в своем собственном компоненте, и обернуть все эти внешние компоненты/библиотеки в некоторый код, который вы будете экспортировать из DLL. Затем создайте свой компонент, не используя внешние компоненты напрямую, а DLL, которую вы создали. Вы не можете в своем компоненте «использовать» любую единицу других внешних компонентов/библиотек. Вы должны создать новое подразделение со всеми типами данных и обязательную декларацию для всего, что вы экспортируете из своей DLL. Все это отлично работает, но быстро становится очень сложным для большого количества внешних компонентов или библиотек.

Answer 3

То, что вы испытали, является обычным делом для тех, кто пишет компоненты. Распределение всегда так. Пакеты не переносят другие пакеты, они ссылаются на них. Это по своей природе.

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

В моем случае InnoSetup работает очень хорошо (http://www.jrsoftware.org/isinfo.php).

Answer 4

Я думаю, что у AlexSC есть лучший ответ, но я думаю, что может быть альтернатива, если у вас абсолютно должен быть пользовательский компонент, который не имеет зависимостей.

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

1. Удаление всех зависимости ваш компонент использует

2. В вашем пакете компонентов, удалите вышеуказанный DCP из раздела из пакета требуется.

3. Скопируйте исходные файлы ваших зависимостей на компоненты

При распространении компонента, вы должны будете distibute его с кодом необходимых dependecies

Вы будете работать в проблемы, если вы хотите использовать зависимости отдельно, поскольку Delphi не позволит вам дублировать имена модулей в установленных пакетах.

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

Опять же, у AlexSC есть лучший ответ, а InnoStudio - отличный инструмент.