Пользовательский компонент зависимости ад

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

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

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

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

Ответ 1

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

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

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

Ответ 2

Резюме

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

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

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

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

Время разработки

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

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

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

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

Я обычно помещаю проекты delphi (пакеты) за пределы установочной папки delphi.

Время выполнения

Обычно быстрый способ - поместить файлы ".bpl" ".dcp" в папку Windows (32)/system или аналогичную папку "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...

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

Ответ 3

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

Ответ 4

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

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

  • Удалите все зависимости, используемые вашим компонентом

  • В своем пакете компонентов удалите вышеуказанный dcp из раздела require из вашего пакета.

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

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

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

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

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