Multiple projects that share files

[jhartika]

I have a situation where there are multiple variants that share lot of structure and use work.file_name_pkg.all statements (which is partly to blame for the problems, although it makes some things about variant management easier from build system PoV).
I am using VSCode with VHDL_LS

Now there are few cases where vhdl_ls does not quite work as I hope it would.

1. If I have for example a record type record_type_common1 defined in common1.vhd and it is used in both top_variant1.vhd and top_variant2.vhd. For "Go to Definition" to work correctly I have to define in vhdl_ls.toml two separate libraries for variant1 and variant2 and put common1.vhd separately to both.
   This is very cumbersome when there are lot of common files, but at least it works.
   Putting variant1 and variant2 files in same library does not work because variant1 and variant2 architectures have same names and then duplicate architecture error prevents navigation from both working.
   For this case it would be useful to have ability to list the common files just once and then say that both lib1 and lib2 contain these files
2. If I have two variants of same package, for example measurement_scaling_variant1_pkg.vhd and measurement_scaling_variant2_pkg.vhd that both define package measurement_scaling_pkg. Now if some common.vhd file has use work.measurement_scaling_pkg.all statement, then I can only navigate to the version that was defined first in the vhdl_ls.toml. For this I have not found a workaround.
   Here I would hope to have ability to select which of the multiple packages with same name I want to navigate to.
3. Using glob patterns to get around the issue is also cumbersome because for each library I would need to exclude all the other variants one by one.
   For my case it would be useful if I could just define one pattern that excludes all the variant files and then reinclude specific variant files afterwards.
4. Some parts of the project reside in a submodules that define their own vhdl_ls.toml files. Currently the parent project can't make use of the information in these. The recursive search of .toml files has already been suggested elsewhere, and that is also something that would alleviate my issues.

[libraries]

lib1.files = [
'src/top_variant1.vhd', # uses all the same commonX.vhd files as other variants

'src/common1.vhd',
'src/common2.vhd',
...
'src/common175.vhd',

'src/measurements/measurement_scaling_variant1_pkg.vhd', # Is used by some commonX.vhd file
]


lib2.files = [
'src/top_variant2.vhd',

'src/common1.vhd',
'src/common2.vhd',
...
'src/common175.vhd',

'src/measurements/measurement_scaling_variant2_pkg.vhd', # Is used by some commonX.vhd file
]

[Schottkyc137]

Hi @jhartika
Just to clarify on your issues, could you check whether this is what you mean?

1. I am assuming that your project structure (simplified) looks something like this:

project/
  ├── common/
  │   └── common.vhd
  ├── variant1/
  │   └── top_variant.vhd
  ├── variant2/
  │   └── top_variant.vhd
  └── vhdl_ls.toml

with the following files:

-- common.vhd
package common_pkg is
    type record_type_common is record
        a : integer;
        b : std_logic;
    end record;
end package;

-- top_variant.vhd (Variant 1)
use work.common_pkg.all; -- or `use common.common_pkg.all` ?

entity top is
end entity;

architecture rtl of top is
    signal my_record : record_type_common;
begin
    -- Implementation
end architecture;

-- top_variant.vhd (Variant 2)
use work.common_pkg.all; -- or `use common.common_pkg.all` ?

entity top is
end entity;

architecture rtl of top is
    signal my_record : record_type_common;
begin
    -- Slightly different implementation
end architecture;

Is the only difference between top variant 1 and top variant 2 that they have a different architecture, but share the same entity declaration?

Currently, your approach is to have a vhdl_ls.toml that looks something like this, correct?

[libraries]

lib1.files = [
'common/common1.vhd',
'variant1/top_variant.vhd',
]


lib2.files = [
'common/common1.vhd',
'variant2/top_variant.vhd',
]

i.e., the common1.vhd file is replicated in the lib1 and lib2. Did I understand you correctly?

2. common package that includes packages from either variant:

project/
  ├── common/
  │   └── common.vhd
  ├── variant1/
  │   └── measurement_scaling_variant1_pkg.vhd
  ├── variant2/
  │   └── measurement_scaling_variant2_pkg.vhd
  └── vhdl_ls.toml

where measurement_scaling_variant1_pkg.vhd and measurement_scaling_variant2_pkg.vhd look something like this:

package measurement_scaling_pkg is
    -- different implementations between measurement_scaling_variant1_pkg.vhd and measurement_scaling_variant2_pkg.vhd
end package;

In your common file, you then include it like so:

use work. measurement_scaling_pkg.all; -- When compiling, the 'right' package will be used. vhdl_ls should offer 'go to definition' for both though

package common_pkg is
end package;

3. exclude patterns should already be supported. Please also have a look at the example vhdl_ls.toml file in the Configuration section in the readme to check whether that would fit your use-case.

[jhartika]

Thank you for taking time to answer and understand my issue.

Your understanding of the project structure and my approach is roughly correct

I found a pattern that solves the inability to exclude the wrong variants without excluding the right variant.
Looking at the example was my problem, because example talks about wildcard support instead of glob pattern support. Glob pattern support was mentioned elsewhere in the readme and that solved the problem with exclude patterns.

lib3.exclude = [
'./**/*variant[!3].vhd',
]

So mostly just the problem 2 is left. Where selecting which of the multiple implementations to navigate to defaults to the one encountered first. Otherwise my issue is solved.