tl;dr libVc.a should be rather part of Vc-devel, not in a separate package with
even inverted dependency.

Vc is a set of headers accompanied with a static lib. Designed to enhance a
software by injecting at build-time optimized code for given cpu
architecture(s). With no further runtime dependencies for the created software.
Which also means, there is no dynamic lib variant of Vc, only the static lib.

So when using Vc while developing/building a software, one would install
Vc-devel following the usual naming patterns.
Just, with current packaging of Vc this does not work out. Because for some
reason the static lib is split into a separate package Vc-devel-static (and the
cmake find/config package is broken as it still returns Vc_FOUND as true even
with Vc_LIBRARIES set to NOTFOUND). So during the build the linker will report
missing symbols due to no libVc.a present.

The current packaging comes as surprise and seems to derive from (by me)
expected patterns. At least I can not see a reason here for splitting off the
static lib into a separate package and, even more surprising, have it depend on
the package with the headers, while at most it should be the other way around,
the headers depending on the actual lib.

I do not have experience with other static libs and how they are packaged (and
if only by tradition), so perhaps I just ran into things with wrong
assumptions. Just reporting what seems strange to me :)

See https://build.opensuse.org/package/view_file/openSUSE:Factory/Vc/Vc.spec

Known user, which uses Vc-devel-static as needed currently:
https://build.opensuse.org/package/view_file/KDE:Unstable:Extra/krita/krita.spec