How I fixed LSP (sorta) and a question

[Brandon Staggs 364]

For years LSP has been broken on our very large code base. The main problem being "Find Declaration" is non-functional. We also experience problems when switching between Win64 and MacOS build targets; usually doing so without cleaning the project results in the IDE crashing or the compiler crashing or both. I complained about this earlier today in this post:

 

 

Today, I was stepping through code in our MacOS build when I noticed that the IDE was taking me to the wrong source file. That clued me into what was going on.

 

This project has about 40 local copies of Delphi source files to fix various bugs and add some needed access to private fields, etc. (Trust me, we hate to do this, we don't want to do this, but when the FMX code base assumes only one thread will ever want to use bitmaps and stuff like that, we have no choice). Of course these local copies appear first in the search path. This naturally necessitates that the other source files are rebuilt, and they are listed in the search path, lower down. The compiler works perfectly fine; our modifications are built without issue.

 

But the IDE and LSP hate this. While stepping through code, it took me to the original FMX.COntrols.pas file, not the local copy that is being compiled into the build. No amount of tweaking the search path or browsing path helped. This got me thinking that this could be related to code navigation issues.

 

So I went into the Rad Studio installation folder and renamed all of the source files for which we have a local copy, so that it would be impossible for the IDE or LSP Server to reach them.

 

And like magic, every single problem I have been having with code navigation suddenly went away.

 

Even switching between MacOS and Win64 build targets and compiling became a seamless operation.

 

So, it appears clear that the LSP Server and IDE do not take the same clues as the compiler or linker or whatever when it comes to search paths. And chaos ensues, due probably to incompatible interfaces that exist between unmodified fmx classes and our local forks.

 

Now I could be overstating the effectiveness of this fix, but I spent an hour doing things I know break the IDE and they all worked.

 

The problem is now I have gone nuclear on the Delphi source folders and no other projects can use them.

 

What I would like to do is have a different copy of the BDS /source/ folder that is used for this project. But we already know a wholesale copy into the search path won't fix it, because those files are already there. We need the IDE to treat a different folder as canonical for $BDS/source.

 

I already use the -r command line switch for the IDE to isolate this project into its own registry hive, but I could not find a way to override the BDS variable (nor do I think that is the right solution).

 

This brings me to my question -- going to Tools/Options and trying to override the BDS environment variable creates an error since it is "built-in." My current solution is clunky -- maintain two source copies of the BDS source folder, one with all the files and one with files removed that we have local copies of -- and switch between the two depending on what project I am working on. But is there a way to tell the IDE and LSP Server to use a different source folder? (Probably not, because if so, it would already be working based on the project settings, LOL!)

 

If I can get time I may try to make a small project that reproduces one of these problems, but this is a million+ line project and it could have to do with a combination of factors, not just the fact that we have local copies of stuff like FMX.Controls with incompatible interfaces.

Edited March 19 by Brandon Staggs

[Uwe Raabe 2127]

Wouldn't it be sufficient to adjust the entries in Tools > Options > Language > Delphi Options > Library -> Browsing path?

[Darian Miller 375]

Can you create a QP issue for this finding?  It may help fix some outstanding issues...

[dwrbudr 8]

Do not use search paths. Add the modified VCL units first in the .dpr file like:
 

  Vcl.Dialogs in '..\Delphi Fixes\Vcl.Dialogs.pas',

 

[GabrielMoraru 32]

11 hours ago, Brandon Staggs said:

I already use the -r command line switch for the IDE to isolate this project into its own registry hive...
--
What I would like to do is have a different copy of the BDS /source/ folder that is used for this project.

The crazy things we do for our beloved LSP 🙂 
_________
 

I feel you. We are in the same situation - copy of vcl.grids. LSP acts strangely, exactly as you described. It is mostly unreliable or take ages to respond.

Question: Why don't you let all projects use the modified Delphi files? 
Then you don't need the two copies.

Edited Thursday at 08:58 AM by GabrielMoraru

[GabrielMoraru 32]

5 hours ago, dwrbudr said:

Do not use search paths. Add the modified VCL units first in the .dpr file like:   Vcl.Dialogs in '..\Delphi Fixes\Vcl.Dialogs.pas',

I worked on multiple projects that had multi-million SLOC.
The last thing that you want to do when you have such project is to add more files to it! (Especially BIG files like the ones of Delphi VCL).

Even if we are in C++, the compilation time could be quite high!

Edited Thursday at 08:57 AM by GabrielMoraru

[Brandon Staggs 364]

10 hours ago, Darian Miller said:

Can you create a QP issue for this finding?  It may help fix some outstanding issues...

I'd like to, but without including an example project that shows the problem, it will be ignored. I haven't had time to see if I can make a small application that uses a local copy of an rtl or fmx unit with an incompatible interface to see if it works as an example. And the LSP issues we experienced were intermittent -- LSP would be okay 20% of the time, so I suspect it's a combination of factors.

Edited Thursday at 12:46 PM by Brandon Staggs

[Brandon Staggs 364]

13 hours ago, Uwe Raabe said:

Wouldn't it be sufficient to adjust the entries in Tools > Options > Language > Delphi Options > Library -> Browsing path?

No amount of tweaking the browsing path was able to work around the problem. In fact the reason this took me so long to work around is because I trusted the documentation. I had to actually make the original source files unreachable.

Edited Thursday at 12:47 PM by Brandon Staggs

[Brandon Staggs 364]

8 hours ago, dwrbudr said:

Do not use search paths. Add the modified VCL units first in the .dpr file like:

Without adding the other VCL (or rtl, fmx, etc) paths, the modified pas file will not link with the others. We've modified System.Classes, for example. Almost all of the RTL and FMX units have to be rebuilt.

[Brandon Staggs 364]

3 hours ago, GabrielMoraru said:

Question: Why don't you let all projects use the modified Delphi files? 
Then you don't need the two copies.

The changes are work product for one company. They can't be used by other projects. 

 

I'm sure someone else may suggest a VM. That would work if it wasn't for the fact that our products don't work in a VM which makes developing that way a major pain.

 

What I was left wishing for is a docker container for Windows GUI applications. I'd like to just shove an instance of Delphi into a container so I can run on the metal and modify the installed files without affecting other projects that don't need them.

[Uwe Raabe 2127]

3 hours ago, Brandon Staggs said:

We've modified System.Classes, for example. Almost all of the RTL and FMX units have to be rebuilt.

Shall I read that as we made changes to the interface part?

 

3 hours ago, Brandon Staggs said:

No amount of tweaking the browsing path was able to work around the problem.

Interesting. A short test on my system showed that it was not possible to navigate to any VCL source file when the $(BIN)\source\VCL entry of the browsing path was missing.

 

It's probably not me alone who would be interested in a reproducible test case.

[Brandon Staggs 364]

4 hours ago, Uwe Raabe said:

Shall I read that as we made changes to the interface part?

 

Sure. I've said that three times already in this thread, so that would be appropriate.

Edited Thursday at 08:38 PM by Brandon Staggs

[Brandon Staggs 364]

4 hours ago, Uwe Raabe said:

Interesting. A short test on my system showed that it was not possible to navigate to any VCL source file when the $(BIN)\source\VCL entry of the browsing path was missing.

  

It's probably not me alone who would be interested in a reproducible test case.

Of course. If someone wants to pay me my going rate, I'd stop everything and create one. As it stands, I hope to find time to work on creating one. The million+ lines of code that don't belong to me can't just be posted in attlasian's system.