I have changed the way the search path is handled:
Previously it was added to the FPCOptions string, which is then subsequently taken into account by the codetools.
We have a project with 800 directories, the combined length of the include and unit path is then way over 128k characters.
Since the codetools execute fpc with the FPCOptions on the commandline, this fails because the OS imposes limits on the length of the command-line (32k windows, 64k linux).
Instead, the directories of the workspace are not added in the FPCOptions, but are directly passed to the Lazarus codetools. Since the LSP server does not use the fpc options for anything else than feeding it to codetools,
the resulting behaviour of the codetools is the same.
I also let the socket server write the log output to a file with a larger buffer (it takes seconds to write the 128k path to the logs otherwise). This last change does not affect the 'pasls' process, only the socket server.
Ryan
I have changed the way the search path is handled: Previously it was added to the FPCOptions string, which is then subsequently taken into account by the codetools.
We have a project with 800 directories, the combined length of the include and unit path is then way over 128k characters.
Since the codetools execute fpc with the FPCOptions on the commandline, this fails because the OS imposes limits on the length of the command-line (32k windows, 64k linux).
Instead, the directories of the workspace are not added in the FPCOptions, but are directly passed to the Lazarus codetools. Since the LSP server does not use the fpc options for anything else than feeding it to codetools, the resulting behaviour of the codetools is the same.
I also let the socket server write the log output to a file with a larger buffer (it takes seconds to write the 128k path to the logs otherwise). This last change does not affect the 'pasls' process, only the socket server.