erlang_ls
erlang_ls copied to clipboard
Configuring complex projects
I have two questions about how to configure the server:
- Are vscode workspaces supported? (i.e. with multiple projects, each with its own config)
- I have an important erlide user that has a giant project, with a very weird structure. The code is spread out in several subsystems that depend on each other, and each has their own include directories where sometimes the file names collide. These subsystems are compiled separately, so that's not an issue for the compiler, but it's tricky for other tools. So what I think would fit was a separate erlang_ls.config file for each subsystem, and a way to bind them together (maybe a top config that has a list of sub-projects?) What do you think? Maybe there is a simpler way?
I would like to rewrite erlide to use erlang_ls, to bring the support to Eclipse, but I need to be able to handle this code base. Maybe it's a similar problem to the "OTP config" one (except the subsystems are not apps and not even with a similar structure to each other)?
I think the dir structure can be tackled with appropriate path configs, but having include files (or modules) with the same name in the same erlang_ls project is a problem as erlang_ls uses that as unique key in some tables. What you suggest with multiple erlang_ls;configs is a good idea, but I dont think they can be "connected together" with the current state of erlang_ls. Maybe if multiple Language Servers could discover and talk to each other. (That would be useful for multi-language projects as well) Probably the name clash issue would be good to tackle anyway.
I think it would be good to be able to handle that. The OTP libraries too have some header files with identical names. Most duplicates are in the test or dialyzer directories, but a few are not, httpd.hrl, mod_auth.hrl, edoc_doclet.hrl, OTP-PUB-KEY.hrl and PKCS-FRAME.hrl. I haven't checked if the contents of the files is the same, I suppose it is and then maybe it doesn't really matter (unless making changes to OTP, then you wouldn't want to edit the wrong file).
I second @gomoripeti 's thinking here. Handling conflicting modules/headers is a current limitation and should be considered as a bug. https://github.com/erlang-ls/erlang_ls/issues/358 exists for that.