As far as I know the only pkg-config file provided by Vixl is the one generated by Meson when applying my yet to be merged patch.
That extra include path was needed because I mistakenly thought that adding `vixl` as an include subdirectory was not necessary, but I fixed it in my latest revision - more details here: https://github.com/Linaro/vixl/pull/7#discussion_r778167004
The fix already landed in Debian and Ubuntu, that as far as I know are the only Linux distros that ship my patch, so manually adding that include directory shouldn't be necessary anymore
This makes dynarmic installable, and also adds a CMake package config
file, that allows projects to use `find_package(dynarmic)` to import the
library.
I know #636 adds the same thing, but while experimenting with the
different install options in
https://github.com/merryhime/dynarmic/pull/636#discussion_r725656034
I ended up with a working patch, so I'm proposing this as well. This
implements solution 2.
This adds versioning information to the built library.
When building the shared library on Linux systems, a new object will
be created: libdynarmic.so.5
This is really useful when talking about ABI compatibility.
The variables dynarmic_VERSION and dynarmic_VERSION_MAJOR
are implicitly created when calling project(dynarmic VERSION x.y.z)
Makes Windows builds more standard-compliant. Given we currently make no
use of volatile, and the libraries we currently use don't use it any
meaningful way, this is safe to specify without worrying.
CMake documentation states:
"If this variable is not set, CMake behaves as if it were set to TRUE."
So this isn't needed, as it's the default behavior.
There's currently no way this path can occur and result in any
functioning executable. The recompiler backends are platform-specific.
If those platforms aren't available, then it's quite literally
impossible to use this library for anything meaningful. Instead of
defining a generic architecture and continuing on, notify the developer
that their platform is not currently supported.
* boost is part of the public interface.
* Consider boost a system library so warnings from boost do not cause a build failure.
* If the parent project defines boost, use that.
