Philipp Wagner

I can give it a try in the new year.

Thanks for your work on this. Can you open a pull request once you have code ready to be reviewed? It's significantly easier to see and discuss there than in...

@mithro what would be the goal of such an integration? Specify all source files in bazel description files, and use edalize to - call the EDA tools? - create a...

The ot branch contains various things. * Support for the virtual keyword. That's already merged in upstream FuseSoC at https://github.com/olofk/fusesoc/pull/524. * Support for dependency resolution in generators. That's https://github.com/olofk/fusesoc/pull/391, and...

Thanks for this feature request. While there is certainly value in having a "generic" and core-specific way to describe tool dependencies, there are some rather interesting challenges with it (e.g....

Thanks for your report. I'm not quite sure I fully understand your problem. Can you show the core file in which you specify the dependency to osvvvm? And by "pulling",...

Given your constraint (">=::osvvm:2020.05"), 2021.10 is a valid choice, isn't it? I think we had some confusion there in the past, are you expecting the newest available core to be...

Thanks for the outstanding investigation @GCHQDeveloper963, that's much appreciated! The behavior you're seeing is unexpected (to me) -- version numbers like 2020.04 are certainly valid according to [semver](https://semver.org), and should...

Turns out this is more involved. We only get the list of parameters and their values after we've finished resolving the dependency tree. So we need to do that first,...

That's correct: the versions are expected as major.minor.patch, as documented at https://fusesoc.readthedocs.io/en/latest/user/build_system/dependencies.html. That doesn't necessarily need to stay that way: do you want to attempt a pull request?