Переход на использование пакетов Delphi - пожалуйста, лучшая практика?

Question

Я пытаюсь начать делать свои собственные библиотеки доступными в виде пакетов до компиляции моих приложений с этими пакетами, следовательно, модульный мой код.В течение многих лет я «вроде» разбирался в пакетах, вздыхая с облегчением, когда я загружал пакет компонентов и нажимал «Установить», и это происходит.Я понимаю, что процесс установки компонента (или компонентов) происходит посредством создания BPL, который затем регистрируется в IDE.

Где я начинаю заблудиться, это как сделать файлы доступными, чтобы я могскомпилируйте с ЛЮБОМ пакет ИЛИ предварительно скомпилированные dcu (как это делают сторонние поставщики) и без указания моего проекта все время на исходный код.Я могу создать пакет со следующими настройками:

, где я указал, что весь мой вывод будет идти в 'c: \ scratch \ wow'.После сборки я нахожу TEST.BPL, TEST.DCP и множество DUC.Теперь, когда я указываю другой проект на эту папку для использования DCU, я получаю пропущенную ошибку DFM (один из модулей - форма).Должен ли я вручную копировать необходимые DFM в эту папку вывода?DPK знает об этой форме, так почему бы мне не скопировать DFM для меня?Я предполагаю, что при использовании TEST.BPL этот файл содержит все, но я хочу работать в двух режимах.Конечно, я могу обойти это, включив исходную папку в путь поиска моего проекта, чтобы найти DFM, но сторонние библиотеки, похоже, уже имеют DFM в своей выходной папке.Они установили их там с помощью установщика?Спасибо

вместо

Answer 1

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

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

Вещи, которые я бы поместил в пакеты:

1. Визуальные и невизуальные компоненты Delphi.

2. Вещи, которые обязательно должны быть подключены во время выполнения или пропущены.Например, предположим, что я продаю MetaWare Light и MetaWare Pro, и вместо того, чтобы использовать IFDEFs компилятора для создания другого двоичного файла, я по какой-то причине предпочел просто не поставлять ADVANCEDFEATURE.BPL с моими системами.

Что следует остерегаться с пакетами:

1. Я столкнулся с множеством ошибок компилятора при объединении пакетов с обобщениями.Я также сталкивался с авариями и блокировками IDE в Delphi 2009, 2010, XE и XE2.(Я считаю, что XE3 лучше)

2. Вы должны немного узнать о BorlandMM.dll и управлении общей памятью в мире BPL, прежде чем перейти к нему.Есть некоторые тонкости.

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

4. После того, как вы создали бинарный пакет и отправили его хотя бы одному клиенту, у вас возникли довольно сложные проблемы.Чтобы изменить контракт (этот BPL содержит конкретную сигнатуру или двоичный интерфейс приложения), вы должны быть осторожны в будущем, чтобы никогда не изменять их или смешивать и сопоставлять их.Остерегайтесь ада DLL, даже среди ваших собственных клиентов, и будьте готовы к использованию версий в ваших пакетах.Так же, как пакеты Delphi имеют суффикс версии, я рекомендую использовать суффиксы версии в ваших собственных пакетах сразу и увеличивать их всякий раз, когда изменяется двоичная совместимость.

5. Delphi обрабатывает зависимости между сборкамиПакеты примерно так же, как можно было бы надеяться, что хуже, чем одно монолитное приложение.В моих приложениях, которые интенсивно используют пакеты, я нахожу, что проектным группам, которые содержат несколько пакетов, которые зависят друг от друга, очень сложно управлять и создавать быстро.На самом деле, я обнаружил, что и компиляция, и сборка медленнее и более неприятны, чем в отдельном мегапроекте 750Kline.

Мне действительно интересно, не относитесь ли вы к области пакетов Delphi (вы вздыхаете с облегчением, когда компонент delphi фактически собирается и устанавливается без проблем?), Если вы действительно хотитеполностью перейти в Мир Пакетов.Конечно, вы должны экспериментировать.Но я бы еще не поставил на это ферму.Узнайте больше сначала.

Answer 2

Да, вам следует скопировать файл .dfm в каталог с скомпилированными модулями (.dcus), если это единственный каталог, который вы хотите указать в пути поиска.BPL, конечно, будет содержать .dfms, и вам нужен .dcp, чтобы иметь возможность связать BPL с вашим приложением.

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

Answer 3

Вместо того, чтобы копировать * .DFM вручную, вы можете использовать Событие после сборки (Проект / Опции / Событие сборки), например:

copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”

Answer 4

Я нашел способ сделать это, не перемещая файлы .dfm в каталог файлов .dcu, так что вы можете иметь каталог только для файлов .dcu, один только для файлов .dcp и другой только для файлов .bpl.

Все, что вам нужно сделать, это создать еще один каталог с хорошей структурой, как я.Каталог называется RES, и в него должны быть помещены все файлы ресурсов (файлы .res, а не файлы .dcr), которые используются приложениями, скомпилированными с использованием ваших пакетов (компонентов).В пути к библиотеке Delphi вы должны включить в дополнение к каталогу DCU (у вас уже должен быть) каталог с именем RES.

В вашем компоненте (время разработки) делайте все, что вы хотите с формой (проектируйте еепоставить другие компоненты и т. д.).В исходном коде модуля вы заменяете {$ R * .dfm} на {$ R UnitName.dfm}.При этом сохраните все и закройте DPK.Теперь переместите файл .dfm (не копируйте, переместите!) В папку RES (файл .dfm - это файл ресурсов в Delphi. Директива {$ R} является доказательством!) И после этого снова откройте DPK, чтобы понятьчто изменилось.

Сначала поймите, что вы не можете открыть форму (F12) из ​​его устройства, хотя Delphi не выдавала ошибку об "DFM отсутствует".

Теперь выполните Buildна вашем пакете, а затем установите его.Понял снова?Ошибки не отображаются!Это произошло потому, что вы указали расположение файла .dfm в пути поиска библиотеки Delphi (каталог RES).

Готово!Вы можете использовать свой компонент, и dfm будет найден, когда ваш компонент включен в приложение.

Многие из вас теперь могут сказать, что таким образом я больше не смогу визуально редактировать форму во время разработки компонента.,Да, это правда, но если вы подумаете об этом, почему я хотел бы так часто менять форму на компонент, который на практике следует использовать только и слегка отредактировать?Сделайте свои собственные выводы;)