TerosTechnology
Improve project manager with RustHDL
Currently, TerosHDL saves the RustHDL project file vhdl_ls.toml as .vhdl_ls.toml in the user's home directory (~ on Linux and C:/Users/<username> on Windows). This is fine for one-off development, but can quickly become annoying when using remote extensions or when trying to maintain multiple repositories throughout the day locally. I do all of these, and I've found it kind of annoying to constantly go into Teros, create an empty project, and finally add all of the files.
What this does is store the project information for isolated projects all in ~/.vhdl_ls.toml which is really painful when working in multiple workspaces that might have the same libraries. Sometimes go-to definition takes you to the wrong file that you're trying to get to and other times you get errors about an entity/arch/package/etc. already being declared in the library.
This doesn't scale well with not only large projects but maintaining many repos and branches in different workspaces. Instead, I think the project manager should be isolated to the workspace root. I think that Teros should look in the workspace root for a specific file (EDAM or CSV file list?) similar to RustHDL allowing vhdl_ls.toml to be defined in the workspace root along with allowing the user to select files in the GUI identically to how it is set up now.
I would be interested in hearing your thoughts on this as I don't fully understand the vision and target audience. I like the idea of the project manager, but I work between so many different systems and networks that I find it difficult to maintain. What I have resorted to is not adding anything to the project manager and continuing to save a vhdl_ls.toml in the root of my workspaces.
The other thing about using a workspace is the project manager wouldn't need to require the user to add run.py files to the project. They could be searched for in the workspace and added that way instead.
Thank you for your suggestion!! :) I will try to explain the TerosHDL porject philosophy.
From user point of view vhdl_ls.toml file doesn't exist. I plan to move it to a hidden folder. TerosHDL project manager is independent of VSCode file manager. You don't need a workspace folder in VSCode to have a TerosHDL project. And in the TerosHDL project manager the files could be cross folder.
If you work with N project you could create N TerosHDL projects. If there are no bugs you could have N projects, but only the active project will be lint by RustHDL. So you can switch between projects and you don't need to delete/add them.
Another idea is to have the possibility to add common libraries to all projects. To create a tab in the project configuration with "common libraries". So you could set the path of a CSV with the common libraries. TerosHDL will add them automatically in each project. And a check button to enable/disable.
About the run.py I think the same. The project manager should be independent of the VSCode workspace. It will take more sense in the future when we integrate VUnit, cocotb... and external simulators (Verilator, ModelSim, GHDL...). The run.py it will be only another file type. You will be able to select as tool: VUnit, Cocotb or simulator.
Then from my point of view it doesn't make sense to scan the workspace (for VUnit), add the files (for exernal simulator)...
From user point of view vhdl_ls.toml file doesn't exist. I plan to move it to a hidden folder.
Okay, how will the project manager handle this? Currently, these are the ways to provide a TOML for RustHDL. Are you planning to somehow define an env variable and use the second option? I'm unsure, though, about how RustHDL knows what the project root directory is. I haven't looked at the VSC extension code. Does it pass a directory to the LS somehow? In the latter case, option 3 seems the most natural for managing many projects.
In regards to automating the project manager sources, is the plan to stick with the file list CSV that is present in v0.1.91?
TerosHDL project manager is independent of VSCode file manager. You don't need a workspace folder in VSCode to have a TerosHDL project. And in the TerosHDL project manager the files could be cross folder.
If you work with N project you could create N TerosHDL projects. If there are no bugs you could have N projects, but only the active project will be lint by RustHDL. So you can switch between projects and you don't need to delete/add them.
What are the pros and cons of doing this? I guess what I'm trying to get at as this feels like duplicating work done by the VSC developers which carry a maintenance burden for adding/supporting features already present in VSC. The way I see it is VSC already allows you to open multiple workspaces without adding/deleting anything. Sure, when doing this the workspace is some directory locally or remote and doesn't have a concept of the underlying project language, but this is accomplished with some configuration by the user (project file in root for the extension for example). The other thing about workspaces in VSC is you can apply settings, extensions, etc. locally to a workspace.
From my perspective as a user of your extension, I see the project manager more as a complement to the "expected" VSC flow and not the entry point to an HDL project. The core of my proposal is that the project manager tab in the GUI acquires its information from a workspace, if it exists (if it doesn't exist then nothing changes to how it currently works). I would think that by opening a directory that contains an EDAM or CSV, the project manager would then add this as a project to the view. If the user had multiple workspaces open then the project manager would have a 1:1 mapping of this along with all of the files present in each of the project files with no action required by the user. The user could select an active project identically to how it is done now, generate documentation for the entire project, navigate to files in libraries easier than the Explorer tab, derive all run.py tests in that workspace automatically (and list them in their associated libraries), etc.. My argument boils down to the following points:
- Adding an easier entry point to the project manager for multiple large projects
- Automating the entry point to avoid clicking through the GUI
This is not a critique of your work by any means, I am just trying to understand what the advantage is. My expertise is VHDL and verification, so I could very easily be missing some key piece to the conversation since I am not familiar with developing an extension or LS for VSC.
Another idea is to have the possibility to add common libraries to all projects. To create a tab in the project configuration with "common libraries". So you could set the path of a CSV with the common libraries. TerosHDL will add them automatically in each project. And a check button to enable/disable.
Can you provide insight about what use-case this serves? I personally don't see value here, but I could have tunnel vision based on how my companies development flow works. In our flow, we would clone a project which also clones all common external repositories, use our python environment to generate the project file, and add the project to the project manager. This way, the project is isolated from everything else we are working on. Even when working in a common repository and not a project that still has dependencies, our python environment takes care of fetching these externals such that this wouldn't be useful, at least for us.
Again, I am not criticizing the work y'all have done as I think this tool fills the gap in an area where many HDL developers get frustrated with the lack of free, good-quality tools. I just want to provide insight into our flow at a large company, offer my opinions/suggestions, and ask questions to better understand the long-term visions for the extension.
Disregard my last 2 paragraphs, I see the use case now! Libraries like VUnit, OSVVM, PoC, Vivado libraries like unisim...