Ад зависимости пользовательских компонентов

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

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

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

Резюме

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

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

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

Это также зависит от того, какую версию Delphi вы используете.

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

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

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

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

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

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

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

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

Ваше здоровье.

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

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

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

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

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

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

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

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

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

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