Auto-generate .vhdl_ls.toml for VS Code VHDL LS from OSVVM build flow

[BekdoucheAmine]

Description

This PR introduces a TCL-based solution to automatically generate the VS Code VHDL Language Server configuration file (.vhdl_ls.toml) directly from the OSVVM build process.

Implementation

• Added Scripts/VendorScripts_GenerateVhdlLsToml.tcl
• Added GenerateVhdlLsToml procedure for VHDL LS integration in Scripts/StartUp.tcl
• Reuses the OSVVM vendor script mechanism (vendor_analyze_vhdl)
• Hooks into the standard build flow
• Collects analyzed VHDL files per library
• Generates .vhdl_ls.toml grouped by [libraries.<name>] in the user workspace
• Non-intrusive: does not change existing build behavior

[libraries.osvvm]
files = [
    '<OSVVM_ROOT>/osvvm/IfElsePkg.vhd',
    '<OSVVM_ROOT>/osvvm/OsvvmTypesPkg.vhd',
    ... 
    '<OSVVM_ROOT>/osvvm/OsvvmContext.vhd',
  ]
  
[libraries.OSVVM_Common]
files = [
    '<OSVVM_ROOT>/Common/src/ModelParametersPtPkg.vhd',
    ... 
    '<OSVVM_ROOT>/Common/src/OsvvmCommonContext.vhd',
  ]
  
[libraries.osvvm_uart]
Files = [
    '<OSVVM_ROOT>/UART/src/UartTbPkg.vhd',
    ... 
    '<OSVVM_ROOT>/UART/src/UartRx.vhd',
  ]
  
# ... remaining libraries omitted for brevity ...

---

Usage

source ../OsvvmLibraries/Scripts/StartUp.tcl
GenerateVhdlLsToml ../OsvvmLibraries

This will:

• Run the OSVVM build flow
• Capture analyzed VHDL files per library
• Generate/update .vhdl_ls.toml
• Restore the default OSVVM script behavior

Notes

• Paths are currently normalized; relative-path handling can be refined later depending on workspace conventions.
• The feature follows the approach discussed in Issue Auto-generate VHDL LS .toml library configuration from OSVVM .pro files #72 and builds on the existing VendorScripts_CompileList.tcl methodology.

[BekdoucheAmine]

Hi @JimLewis I've implemented what we discussed in Issue #72. I'll look into VHDL LS and check if relative paths can be used within the .toml file and I'll get back to you.

[BekdoucheAmine]

A variable can be added to the GenerateVhdlLsToml to indicate where the .toml file should be stored.

[JimLewis]

You are moving faster than I am. I have browsed your pull request and hope to do a full review this weekend.

Here is my browsing level review.
I noted you are creating the TOML file in a single pass. Good catch on the non-contiguous usage of libraries - that is indeed a possibility. I think the approach though is awkward since looks like you are re-reading the toml file to check if the libary is already used. I think you could potentially improve this by either

• Creating a Tcl dictionary structure with the designs library and file structure in it (this is probably the harder path)
• Or - Create temporary files for each library (like CompileList does) and then read these after the run. If these were in a subdirectory they would be easy to glob and easy to delete when done.

For either of the suggestions above to work, you have to create the fiinal Toml file when the build finishes. Luckily this is easy (thanks to Issues from Markus Ferringer). Simply overload the default CallbackAfter_Build. The default is in CallbackDefaults.tcl. You would add the following to your VendorScripts_*.tcl file.

  proc CallbackAfter_Build {Path_Or_File args} {
      # Do stuff to create the toml file from the dictionary or separate files
  }

A user can add your proposed variable, perhaps TomlTargetDirectory, to their OsvvmScriptsLocal. When the scripts are run, if that TomlTargetDirectory exists, they can use it, otherwise use the CurrentSimulationDirectory. For information on OsvvmScriptsLocal.tcl see OSVVM Settings User Guide. If there is no variable defining TomlTargetDirectory, a user can cd to the directory in which to create the toml and run the build. That way the toml is created in the right place with paths that are correct whether they are done with relative (ask @Paebbels if this is necessary - I suspect yes) or absolute paths.

Initially I did not like the support stuff for toml files being in VendorScripts_*.tcl, but it is growing on me - I suspect it probably belongs there.

The current working library for OSVVM (set by the library command) is in the variable ::osvvm::VhdlWorkingLibrary.

For now, GenerateVhdlLsToml should be in OsvvmScriptsCore.tcl - just before the exports - rather than in StartUp.tcl (as no subprograms go in there). Since this is in the OSVVM context, an export (see bottom of file) will be needed. If you like, I can do this after the doing the pull request. Note it move again at a later date when OsvvmScriptsCore gets refactored.