[Clarification] Pass multiple wave.do scripts

[nselvara]

Hi guys, I would like to pass multiple wave.do files, which are at the same locations as the testbenches are, however, passing one do script file can be done via modelsim.init_file.gui but if I want to pass multiple wave.do files, as I want to run all testbense

Hi guys, when I want to run one testbench, I know how to pass wave.do script via modelsim.init_file.gui param. However, if I want to run all testbenches in GUI mode, I don't know how I can pass multiple wave.do scripts. May I use this param: modelsim.vsim_flags.gui, will this work as well?
I found this #615, but I see, it's not done yet.

[LarsAsplund]

Is your use case solved by #1033 which was merged a few days ago?

[nselvara]

This seems the solution!
But this activehdl_gui.do is always loaded from ./vunit_out/modelsim folder, right?
So when one uses the --clean option, that file gets deleted, not?
If not or the workaround is just to create a new file with this name would that should work, I guess.

[LarsAsplund]

The string pointing to the tcl/do would normally be a full path so the file can be located anywhere.

[nselvara]

Ok, then I think my problem got solved by this PR. I have to wait for the release of v5.0.0, because I don't compile from source. Thank you very much for the assistance.

[LarsAsplund]

Note that running the development version of VUnit is very straight-forward. Simply follow these steps

[nselvara]

Thank you for the instruction. The problem is more that in our company we don't install development releases but we rather fix to stable versions.
But I try it privately to also check the #1030 as well.

[LarsAsplund]

Yeah, that is common policy. The other common approach is to always stay in sync with HEAD. Quite the opposite. It should be said that we do not develop on the master branch. What goes in there has been tested. Sometimes there are failing tests but that is usually due to some Python linting rules. Since we always use the latest rules, we may fail if there has been updates to the rule sets.

Since 5.0.0 is a major release where we want to bring in all breaking changes we have in mind, it may take a while to release. If it wasn't for that, we would already have released what we have now. From that point of view, it is as stable as any release.

My current client also prefers using a released tar.gz file so I simply build an unofficial build, see https://vunit.github.io/contributing.html#making-releases. (some modifications are needed since you're not pushing the release upstreams)

[nselvara]

Yeah, I see your argument. It's a bit hard to change the policy for this particular case, as it's not a feature that we're very much dependent on. Do you guys have also a beta-channel on pip?
This is what we actually use to install the requirements for the venv. That would make it easier convincing to change it.

[LarsAsplund]

We don't, but I think that we probably should.

[nselvara]

That would be actually cool though. 😄