Closed a-will closed 10 months ago
The prior test case did not actually test the suggested specs outlined in https://github.com/olofk/fusesoc/issues/235
Now to use the bus, you need to explicitly choose which "provider" (implementation) of vendor:bus:config_default you want to include
Before the first commit here, that test case did not have a core that explicitly chose its implementation, so the bugs have been hidden.
This change still doesn't handle the case where no implementation is specified in the dependency tree (which probably should result in an error). In that case, fusesoc's dependency solver would pick effectively arbitrarily.
I'm not super familiar with the code around the virtual / provides support, since that was written by other people, but I see the issue you are solving here and I trust it's doing the right thing. Just to be sure, is this one good to go, or do you want to fix the issue you mention in the last paragraph first?
Offhand, I'm not sure how best to fix fusesoc's not reporting an error if no implementing core is part of the dependency tree. The modeling of a package repo with the SAT solver may not allow us to express the relationships we want.
So... this PR is at least an improvement that picks the desired core when it is specified. Good to go, I'd say 😄
FYI, I'm also unable to improve error messages. I have tried, but failed miserably at understanding the internals of the dependency manager I shoe-horned into FuseSoC. I really want to replace that with a custom one for several reasons, but until then we will have to live with it.
Picked and pushed! Thank you for your contributions
Add "conflicts" constraints for each core implementing virtual VLNVs, so no two cores implementing the same virtual VLNV may be selected simultaneously.
This change should prevent more than a single implementing core from being selected as the implementation for a virtual VLNV, and when there is an explicit dependency in the tree, that one should be selected.