Как локальные копии исходных файлов Delphi нарушают работу LSP и как это исправить.

Delphi , Программа и Интерфейс , Приложение своё

Проблемы с LSP в Delphi при использовании локальных копий исходных файлов и способы их решения

Введение

Многие разработчики Delphi сталкиваются с необходимостью модификации стандартных исходных файлов RTL, VCL или FMX для исправления ошибок или добавления функциональности. Однако это часто приводит к проблемам с Language Server Protocol (LSP) в IDE, особенно с функцией "Find Declaration". В этой статье мы рассмотрим причины этих проблем и предложим несколько решений.

Проблема: конфликт между компилятором и LSP

Как показал опыт Brandon Staggs, основная проблема возникает, когда:

1. У вас есть локальные копии стандартных файлов Delphi (например, FMX.Controls.pas)
2. Эти файлы находятся в начале пути поиска (search path)
3. LSP и IDE продолжают ссылаться на оригинальные файлы из папки установки Delphi

Результат: - Компилятор корректно использует модифицированные файлы - LSP и навигация по коду ссылаются на оригинальные файлы - Возникают ошибки при переключении между платформами (Win64/MacOS) - IDE может аварийно завершаться

Почему это происходит?

Компилятор и LSP используют разные механизмы для поиска исходных файлов:

1. Компилятор строго следует порядку в search path
2. LSP может кэшировать пути или использовать дополнительные механизмы поиска
3. При изменении интерфейсов (interface section) в модифицированных файлах LSP теряет синхронизацию

Решение 1: Физическое удаление оригинальных файлов (радикальный метод)

Как показал Brandon, переименование или удаление оригинальных файлов в папке установки Delphi решает проблему:

// До:
IDE использует: C:\Program Files\Embarcadero\...\FMX.Controls.pas
Компилятор использует: D:\MyProject\Patched\FMX.Controls.pas

// После удаления оригинального файла:
IDE вынуждена использовать: D:\MyProject\Patched\FMX.Controls.pas

Плюсы: - Немедленно решает проблему - Просто в реализации

Минусы: - Ломает другие проекты, использующие стандартные файлы - Требует ручного вмешательства при обновлениях Delphi

Решение 2: Использование параметра -r для изоляции реестра

Brandon упоминает использование параметра командной строки -r для изоляции настроек IDE:

bds.exe -rMySpecialRegistryHive

Плюсы: - Изолирует настройки IDE для конкретного проекта - Позволяет иметь отдельные browsing paths

Минусы: - Не решает проблему с путями к исходным файлам - Требует ручного управления разными конфигурациями

Решение 3: Явное указание модифицированных файлов в .dpr

Как предложил dwrbudr, можно явно указать модифицированные файлы в .dpr:

program MyProject;

uses
  Vcl.Dialogs in '..\Delphi Fixes\Vcl.Dialogs.pas',
  // остальные модули...

Плюсы: - Четкое указание, какие файлы использовать - Не зависит от search path

Минусы: - Увеличивает размер .dpr - Неудобно для больших проектов с множеством модифицированных файлов - Не решает проблему полностью, так как другие модули могут ссылаться на оригиналы

Решение 4: Создание кастомного "BDS" пути (альтернативное решение)

Поскольку напрямую изменить переменную $(BDS) нельзя, можно:

1. Создать копию папки с исходниками Delphi
2. Удалить или модифицировать нужные файлы в этой копии
3. В настройках проекта добавить этот путь в начало browsing path

Реализация:

1. Скопируйте папку C:\Program Files\Embarcadero\...\source в другое место
2. В Tools > Options > Language > Delphi Options > Library:
3. Добавьте ваш кастомный путь в начало Browsing path
4. Уберите или закомментируйте стандартный $(BDS)\source

Плюсы: - Не требует модификации оригинальных файлов - Позволяет иметь разные конфигурации для разных проектов

Минусы: - Требует много места на диске - Необходимо обновлять копию при апгрейдах Delphi

Решение 5: Использование conditional defines и include-файлов

Для небольших изменений можно использовать conditional defines:

unit FMX.Controls;

interface

{$IFDEF MY_CUSTOM_MODIFICATIONS}
// Ваши модификации
{$ELSE}
// Оригинальный код
{$ENDIF}

Затем в проекте задать MY_CUSTOM_MODIFICATIONS в conditional defines.

Плюсы: - Не требует дублирования всего файла - Легко включать/выключать изменения

Минусы: - Подходит только для небольших изменений - Может усложнить чтение кода

Решение 6: Создание патчей во время сборки

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

1. Хранить только различия (diff) в репозитории
2. Перед компиляцией применять патчи к копии оригинальных файлов
3. Использовать эти временные файлы для компиляции

Плюсы: - Минимальное дублирование кода - Легко обновлять при новых версиях Delphi

Минусы: - Сложная настройка - Медленнее компиляция

Заключение

Проблема с LSP при использовании модифицированных исходных файлов Delphi - серьезное препятствие для разработчиков. Каждое из предложенных решений имеет свои преимущества и недостатки. Для крупных проектов с множеством изменений наиболее надежным решением пока остается создание изолированной копии исходных файлов Delphi.

Embarcadero необходимо улучшить обработку search paths в LSP, чтобы он следовал тем же правилам, что и компилятор. Пока этого не произошло, разработчикам приходится использовать обходные пути.

Если вы столкнулись с подобной проблемой, попробуйте начать с самого простого решения - явного указания модифицированных файлов в .dpr, и если это не поможет, переходите к более сложным вариантам, таким как изолированная копия исходников.

Создано по материалам из источника по ссылке.

Статья описывает проблемы с Language Server Protocol в Delphi при использовании локальных копий исходных файлов и предлагает шесть способов их решения, включая радикальные методы и более гибкие подходы.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Приложение своё ::