This is gross and looks terrible, but I'm not entirely sure how else to
do this.
And cmake is an inferior methodology, TBH, since it is effectively the
same as our own builtins. However, cmake also handles some bizarre
Windows library names whose provenance I'm not entirely sure of, in
addition to implementing the usual excessive pattern of hardcoded search
directories. So, this may be useful, at least on Windows, as a fallback.
(I am not really interested in offering feature compatibility with cmake
for a bunch of bizarre naming schemes that ***aren't the official cmake
library names***, so if cmake allows that and people really feel they
need it, all the more power to them.)
Nevertheless, I believe if it got found via our system dependency class,
it will always provide results which are just as functional as cmake.
cmake can only find openssl installations that would otherwise be
missed.
This also avoids the case where users did
```
dependency('OpenSSL', modules: [...], method: 'cmake')
```
and expected it to work, since our builtin dependency supersedes the
divergent case and didn't previously allow the cmake method. I don't
know why they would do such a thing, but who knows... it is always
possible.
For dependencies that on some systems are built into libc etc. and don't
need to be separately linked. This is distinct from "system"
dependencies which add linker args.
This allow mypy to catch cases where we accidently assign the dependency
name to the type_name, as it sees them as having different types (though
at runtime they're all strings).
Eli Schwartz
Christian Clauss
Dylan Baker
Daniel Mensinger