This is helpful on systems with multiple LLVM installations.
For example, OpenBSD ships with LLVM in the base system, but without
support for extra targets.
A full LLVM version can be installed using the ports system, but even
when it is, `cmake` is not going to pick it up unless `/usr/local` is
explicitly added to the `cmake` search paths.
Having the full `llvm-config` path printed on error is helpful to
understand that the detected LLVM version was not the expected one.
* don't unconditionally pass -lz3 for mingw builds. If mingw builds
require this then the llvm-config executable should put it as part of
--system-libs. If there is a bug and it does not do that, and we need
a workaround, then the workaround should be an explicit cmake option.
* don't link libstage2.a against -lntdll. This causes zig to set
`builtin.link_mode == .Dynamic` and include the TLS definitions,
which then collide with the mingw-w64 symbols. This should probably
be addressed separately, but for now this solves the problem and
there is no reason to link a static library against a DLL.
* Findllvm.cmake no longer treats the libraries as "optional" and will
emit a cmake error if one is not found. Additionally, the
not-required LLVM library LLVMTableGen is omitted.
Match package-name case from CMakeLists.txt .
New warning sample:
The package name passed to `find_package_handle_standard_args` (LLVM) does
not match the name of the calling package (llvm). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Distro's llvm usually have a 6.0 suffix.Any custom llvm build
names the binary as llvm-config.Keeping 6.0 variant first causes
the distro's llvm to be compiled in place of a custom one even if
given using CMAKE_PREFIX_PATH.
