vhdl_ls.toml for Language Server client

[Bochlin]

I've started to implement support for standard libraries, vendor libraries and some of the more prominent open source libraries (e.g. VUnit) in VHDL LS. I would like to do this by letting the extension maintain its own vhdl_ls.toml file. The user would be able to select which libraries to enable (including install dirs in some cases) and the client then generates a vhdl_ls.toml pointing out the standard/vendor libraries. The generated file would be local to the project (stored somewhere in .vscode). To do this I need a way to pass this file to vhdl_ls. I believe that the easiest way is as a command line parameter to vhdl_ls but I'm open for any suggestions.

Suggestion:
Add a command line parameter to vhdl_ls to point out a specific vhdl_ls.toml, priority according to list below:

1. A file named .vhdl_ls.toml in the user home folder.
2. A file name from the VHDL_LS_CONFIG environment variable.
3. Command line parameter ...
4. A file named vhdl_ls.toml in the workspace root.

[kraigher]

Do people really want to depend so much on the local workstation environment? Should not third party dependencies be explicitly managed? I mean to me it seems like a source of problems where the language server points to one version of VUnit/OSVVM when another one is in fact in use when running from command line. In my opinion one should strive for single source of information and then it seems strange that this configuration should be embedded in a language server plugin which is unlikely to be the source for your build script or compile script.

Also in the future maybe vhdl_ls.toml is the input to a linter that runs on command line in a CI-setting. It seems one would like to ensure consistency between different machines.

Wouldn't it be better if the vscode extension offered to change the users vhdl_ls.toml in the HOME folder instead?

[Bochlin]

For the standard and IEEE libraries it works to modify the HOME folder configuration to point to libraries in the VHDL LS extension's install folder. It would not ensure consistency though as the workspace configuration would not have a reference to the standard libraries and the library source would be in the VSCode extension installation. Maybe it's worth it in the long run to have native support in vhdl_ls for these libraries by having them compiled into the binary.

The main goal for me is to at least meet (what I believe is) the user's expectation that the standard and IEEE libraries work out of the box. This can be met by modifying any of the existing configuration files (with the user's consent). It should be possible to support vendor libraries in the same way.

And, yes I agree that the fewer sources of information there are, the better it is.

Feel free to close the issue.

[kraigher]

I think we should strive for the standard and ieee libraries to be part of a "vhdl ls" installation toghether with and with the same lifecycle as the vhdl_ls binary. The vhdl_ls binary would be able to find them via a relative path. The main reason I have not done it yet is the unclear legal situation around ieee-libaries but maybe it is nothing to worry about since GHDL ships them after all.

[Bochlin]

They recently (not sure when) changed the copyright for the IEEE libraries (bold part my emphasis). My interpretation is that at least the 2008 libraries downloaded from IEEE SA can now be freely distributed .

-- Copyright © 2008 by IEEE.
--
-- This source file is an essential part of IEEE Std 1076-2008,
-- IEEE Standard VHDL Language Reference Manual. Verbatim copies of this
-- source file may be used and distributed without restriction.
-- Modifications to this source file as permitted in IEEE Std 1076-2008
-- may also be made and distributed. All other uses require permission
-- from the IEEE Standards Department([email protected]).
-- All other rights reserved.

[kraigher]

Yes now I remember. They allow verbatim copies but the files for download contain a bug that has to be fixed :-)

[kraigher]

I tried the download there. It seems to work. The only problem is it is missing std_logic_textio.

[kraigher]

Maybe we can make an "installation" script that copies the IEEE-files from GHDL-repo.

[umarcor]

IEEE libraries are now open source, and there is a GitLab repo. AFAIK, those bugs are expected to be fixed in master without waiting for new releases of the standard to be published. Unfortunately, I cannot find the repo now...

[umarcor]

This seems to be the upstream: https://opensource.ieee.org/vasg/Packages

But Lars' fork has some more recent commits: https://gitlab.com/LarsAsplund/ieee-open-packages

[kraigher]

But that is the 2019 VHDL packages? They may contain thins that are above 2008?

[umarcor]

The current status of the repo should be VHDL 2008 only. Precisely, it was commented in October 4, 2019 12:19 AM that it would be desirable to have a release/tag before introducing features from VHDL 2019 only. As @LarsAsplund commented (October 4, 2019 8:11 AM), it is still not decided whether to maintain a single branch or keep the one for VHDL 2008 alive.

[kraigher]

In that case I think we should have a CI job that creates a release package with Rust HDL binary together with standard and ieee libraries. The vhdl_ls binary would automatically add std and ieee libraries without vhdl_ls.toml config.

Then we can publish this release to GitHub and extensions such as VSCode can download this release. If desirable we can also build docker images on top of the release.

If anyone want to help out with this I would appreciate it.

[umarcor]

Then we can publish this release to GitHub and extensions such as VSCode can download this release. If desirable we can also build docker images on top of the release.

If anyone want to help out with this I would appreciate it.

Please, open an issue with the requirements: targets OSs, versions of Rust, deps/assets that need to be retrieved, etc.

[kraigher]

I made the following issue: #45