Skip to content

Conversation

@andrevfarias
Copy link
Contributor

Why

  • Avoid cross-version conflicts and enable side-by-side installs for different Delphi versions.

What changed

  • Update client/source/DelphiLint.IDEContext.pas:
    • Scope paths by version:
      • LogDirDelphiLint/<ProductVersion>/logs
      • FSettingsDirDelphiLint/<ProductVersion>
  • Update scripts/TEMPLATE_install.ps1:
    • Install under %APPDATA%\DelphiLint\$RegistryVersion\ (version‑scoped folder).

Impact

  • Clean separation of installed files per Delphi version.
  • Safer upgrades and uninstalls across Delphi versions without interference.

Testing

  • Install Delphilint for two different Delphi versions and verify separate folders under %APPDATA%\DelphiLint\ for logs/settings.
  • Launch IDE and confirm DelphiLint loads and writes logs to the versioned directory.

Notes

  • Existing unversioned appdata folders are not used by new installs. Users may remove old folders manually if desired.

Copy link
Collaborator

@fourls fourls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @andrevfarias, what's the motivation for this change? The DelphiLint appdata folder is intentionally Delphi version-independent because the DelphiLint core is not specific to the Delphi IDE.

This change would also break the VS Code extension because it wouldn't know what Delphi IDE version it's meant to be reading the config for.

@andrevfarias
Copy link
Contributor Author

andrevfarias commented Dec 30, 2025

Hi @fourls, You're right, the .jar file is not specific to the Delphi IDE. But the .bpl generated is, I was using this separation to be able to install running the build and installation script and test DelphiLint on both delphi versions. I was developing the Legacy compatibility so I was working in two different versions and .jar and .bpl must be from the same version/commit, so I nedded to split the installation path in two.

I actually didn't think about VS Code extension, and if you think the split is a bad idea you can close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants