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.pull/9512/merge
parent
0268c25791
commit
96df0fc69e
2 changed files with 11 additions and 4 deletions
Loading…
Reference in new issue