Библиотеки, компоненты. Разные версии в разных проектах

Этот пост является расширенным комментарием к посту Александра Алексеева.

Краткое описание проблемы

Если Вы практикующий программист Delphi, то наверняка сталкивались с проблемой, когда разные проекты работают с некоторой библиотекой (pas-модуль, unit), но каждое приложение работает со своей версией этой библиотеки. Такое часто бывает, когда приложение ссылается на заголовочные файлы GDI+, Direct X или другие модули, портированные в паскаль из C/C++ (бывает так, что одно приложение использует один “порт”, а другое – альтернативный, и эти версии не совместимы между собой). Редко, но бывает и так, что новая версия какого-нибудь, например, XML-парсера не совместима с предыдущей его версией.

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

Пути решения

В случае библиотек, которые не требуют интеграции с IDE, довольно всё просто. Надо в настройках конкретного проекта указать путь (пути) к конкретной версии библиотеки. IDE же при компиляции сначала ищет исходник в путях проекта, а потом уже в путях, прописанных в общих настройках IDE.

А вот с компонентами дела обстоят намного сложнее. Если поменять только пути, то можно добиться стабильной компиляции проекта. Однако при открытии формы, на которой лежит такой компонент, IDE может ругнуться и напортить настройки компонента до неузнаваемости. А происходит это потому, что разные версии компонента могут иметь разный набор published свойств, сохраняемых в dfm-файле. И поэтому приходится заниматься такой вот маятой: удалить старый компонент, установить новый, прописать пути в Library Path, потом удалить новый, установить старый, проверить пути в прописать пути в Library Path… ведение двух проектов превращается…

Стоп. А почему, собственно, так необходимо заниматься переустановкой компонента? Раз нам удалось “обмануть” IDE в первом случае, почему нельзя как-то перехитрить IDE и в случае компонентов? Откуда IDE загружает компоненты в свою палитру? Эта информация хранится в реестре. Для Delphi 7 здесь: HKLM\Software\Borland\Delphi\7.0\Known Packages. В связи с этим, в голову приходит простая мысль: разные версии одного и того же компонента установить в разные каталоги, а перед запуском делфи вносить соответствующую правку в реестр. Заодно можно прям в реестре и менять пути к исходникам библиотек. Довольно просто это сделать экспортом ветки реестра в файл, а затем с помощью bat-файла её загружать. Но это как-то… Несуразно, что ли…

Если Вы посмотрите, как хранятся пути к стандартным делфи-пакетам (а хранятся они примерно так: $(DELPHI)\Bin\имя_пакета.bpl), то более разумное (и красивое) решение придёт сразу: пути к библиотекам и компонентам прописать в реестре с использованием переменных сред окружения.

 

…простите, но мне дальше некогда перефразировать мой комментарий к вышеупомянутому посту, поэтому просто продублирую его…

…проблему разных версий одних и тех же компонентов для разных версий проекта решаю с помощью переменных сред окружения (Environment Variables).
Т.е. все пути в IDE в Library Path прописаны относительными, например так (пишу от фонаря):
$(PAS_SOURCES)\Eureka Log 6\Lib
$(PAS_SOURCES)\Virtual Tree\Sources
В переменной Path есть ссылка на переменную $(BPL).
Ну и собственно заведены переменные PAS_SOURCES (корневой каталог для исходников компонент) и BPL(каталог, куда "сваливаются" BPL и DCP файлы при компиляции и установке пакетов).
И чтобы переключиться с одного проекта на другой остаётся поменять всего лишь эти 2 переменные в одном месте и перезапустить Delphi!
А для того, чтобы можно было одновременно работать в двух Delphi с разными проектами, можно сделать программку-загрузчик, которая будет устанавливать значения этим переменным и запускать Delphi уже в своём окружении. А можно даже и без загрузчика всё в bat-файле сделать (но только будет ненужное консольное окно маячить).
Одно лишь неудобство: процесс инсталляции новых/старых компонентов надо контролировать ручками, что может оказаться довольно трудоёмко. Но оно того стоит.

надеюсь выкрою ещё минутку, чтобы это по красивее написать.