Переход на использование пакетов Delphi - пожалуйста, лучшая практика?
Я пытаюсь начать делать мои собственные библиотеки доступными в виде пакетов до компиляции моих приложений с этими пакетами, следовательно, модульный мой код. В течение многих лет я "вроде" разбирался в пакетах, вздыхая с облегчением, когда я загружал пакет компонентов и нажимал "Установить", и это происходит. Я понимаю, что процесс установки компонента (или компонентов) осуществляется посредством создания BPL, который затем регистрируется в IDE.
Я начинаю заблудиться, как сделать файлы доступными, чтобы я мог скомпилировать с ЛЮБЫМ пакетом ИЛИ предварительно скомпилированными dcu (как это делают сторонние поставщики) и без указания моего проекта все время на исходный код. Я могу создать пакет со следующими настройками:
где я указал, что весь мой вывод будет идти в 'c:\scratch\wow'. После сборки я нахожу TEST.BPL, TEST.DCP и множество DUC. Теперь, когда я указываю другой проект на эту папку, чтобы использовать DCU, я получаю отсутствующую ошибку DFM (один из модулей - форма). Должен ли я вручную копировать необходимые DFM в эту папку вывода? DPK знает об этой форме, так почему бы мне не скопировать DFM для меня? Я предполагаю, что при использовании TEST.BPL этот файл содержит все, но я хочу работать в двух режимах. Конечно, я могу обойти это, включив исходную папку в путь поиска моего проекта, чтобы найти DFM, но сторонние библиотеки, похоже, уже имеют DFM в своей выходной папке. Они установили их там с помощью установщика? Спасибо
вместо
4 ответа
Да, вам следует скопировать файл.dfm в каталог с скомпилированными модулями (.dcus), если это единственный каталог, который вы хотите найти в пути поиска. BPL, конечно, будет содержать.dfms, и вам нужен.dcp, чтобы иметь возможность связать BPL с вашим приложением.
Сторонние инструменты должны были поместить.dfms вместе с.dcus в каталог, используя их установщик.
Как говорят другие, вы можете использовать события после сборки, чтобы скопировать ваши файлы DFM на место. Другие люди используют одноразовый внешний пакетный файл, который копирует DFM в папку DCU.
Лично я вижу очень небольшое преимущество в создании пакетов для вещей, которые не разрабатываются также как компоненты многократного использования. Я также вижу очень небольшое преимущество в разделении существующего приложения на пакеты, когда вам нет необходимости использовать один и тот же подраздел или пакет более одного раза или во время разработки.
Вещи, которые я бы положил в пакеты:
Delphi визуальные и невизуальные компоненты.
Вещи, которые обязательно должны быть подключены во время выполнения или опущены. Например, предположим, что я продаю MetaWare Light и MetaWare Pro, и вместо того, чтобы использовать IFDEFs компилятора для создания другого двоичного файла, я по какой-то причине предпочел просто не поставлять ADVANCEDFEATURE.BPL с моими системами.
Что следует остерегаться с пакетами:
Я столкнулся с множеством ошибок компилятора при объединении пакетов с обобщениями. Я также сталкивался с авариями и блокировками IDE, в Delphi 2009, 2010, XE и XE2. (Я считаю, что XE3 лучше)
Вы должны немного узнать о BorlandMM.dll и управлении общей памятью в мире BPL, прежде чем перейти к нему. Есть некоторые тонкости.
Пакеты ограничивают способность компоновщика решать, что удалять. На самом деле, это в значительной степени разрушает его. Пакеты содержат все, что связано с ними, и ничего общедоступного не может быть удалено.
После того, как вы создали бинарный пакет и отправили его хотя бы одному клиенту, у вас довольно сложно изменить контракт (этот BPL содержит конкретную сигнатуру или двоичный интерфейс приложения), в будущем вы должны быть осторожны, чтобы никогда не изменить их, или смешивать и сочетать их. Остерегайтесь ада DLL, даже среди ваших собственных клиентов, и будьте готовы к использованию версий в ваших пакетах. Так же, как пакеты Delphi имеют суффикс версии, я рекомендую использовать суффиксы версии в ваших собственных пакетах сразу же и увеличивать их всякий раз, когда изменяется двоичная совместимость.
Delphi обрабатывает зависимости между пакетами примерно так же, как и можно надеяться, что не так хорошо, как в одном монолитном приложении. В моих приложениях, которые интенсивно используют пакеты, я нахожу, что проектным группам, которые содержат несколько пакетов, которые зависят друг от друга, очень сложно управлять и создавать быстро. На самом деле, я обнаружил, что и компиляция, и сборка медленнее и более неприятны, чем в отдельном мегапроекте 750Kline.
Мне действительно интересно, не относитесь ли вы к области пакетов Delphi (вы вздыхаете с облегчением, когда компонент delphi фактически собирается и устанавливается без проблем?), Если вы действительно хотите полностью перейти в мир пакетов. Во что бы то ни стало, вы должны экспериментировать. Но я бы еще не поставил на это ферму. Узнайте больше сначала.
Вместо того, чтобы копировать *.DFM вручную, вы можете использовать Событие после сборки (Project/Options/Build Event), например:
copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”
Я нашел способ сделать это, не перемещая файлы.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 будет найден, когда ваш компонент включен в приложение.
Многие из вас теперь могут сказать, что таким образом я больше не смогу визуально редактировать форму во время разработки компонента. Да, это правда, но если вы подумаете об этом, почему я хотел бы так часто менять форму на компонент, который на практике следует использовать только и слегка отредактировать? Сделайте свои собственные выводы;)