The documentation for setting cache entries dicates that the type must
either be BOOL, FILEPATH, PATH, STRING, or INTERNAL (with those exact
casings). Also, given we properly case it in other places, this is just
consistent.
The general convention for CMake is to use lowercase for commands, and
given we also follow that convention through most CMake files, this just
makes it more consistent.
Thin archives contain pathnames pointing to the object files instead of
full copies of the object files. This significantly reduces the disk
usage when building Dolphin.
Size of *.a files: (gcc-8.1.0, Linux amd64)
- Before: 83,876 KB
- After: 1,876 KB
- Diff: -82,000 KB
The resulting binaries are the same as before.
A similar change was implemented in the Linux kernel v4.8:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5967db9af51a84f5e181600954714a9e4c69f1f
We have to decide if we want to link to
libGL.so -- legacy
libOpenGL.so -- GLVND
As we use xxxGetProcAddress, we don't care about feature
levels of the linked library, so we're very fine with the
new way.
Allows us to bring includes and relevant libraries into scope by explicitly declaring linkage against the target
as opposed to using a variable. Also removes the dumping of OProfile includes into the top-level directory.
We already use a custom CMakeLists file for xxhash, so we can just make it's headers
public as part of its target interface.
This way, only libraries that link in the xxhash target will see its headers, as opposed
to every target under the top-level directory.
Adjusts Common to use the ICONV_LIBRARIES variable directly and doesn't
append it to the LIBS variable.
After this, there's only one remaining usage where libraries are added
to the LIBS variable, after which it can be removed once the rest of
the targets are migrated off add_dolphin_library
The only place this library is needed (core) is already linked in the core target.
Also make the linkage private to create linkage failures if the dependency isn't
explicitly linked in elsewhere where it should be.
Reduces the dependency on the LIBS variable.
Makes our libraries explicitly link in which libraries they need.
This makes our dependencies explicit and removes the reliance on the
LIBS variable to contain the libraries that they need.
Both libusbhid (system library) and libhidapi (3rd party library)
provide a function called hid_init. Dolphin was being linked to both.
The WiimoteScannerHidapi constructor was calling hid_init without
arguments. libusbhid's hid_init expects one argument (a file path).
It was being called as if it was defined without arguments, which
resulted in a garbage path being passed in, and because of that,
the Qt GUI was failing to launch with the following error:
'dolphin-emu-qt2: @ : No such file or directory'
Use @Orphis's FindFFmpeg module from ppsspp:
2149d3db7f
From that commit:
> This new module should be able to handle both libraries in the regular
> paths and fallback to pkg-config.
> It is also able to find dynamic libraries, not just static libraries.
> It will generate imported targets with the name FFmpeg::<lib> that you
> can use in your scripts.
Stops CMake from saying "BlueZ NOT found, disabling bluetooth support"
on other OSes. Windows, macOS, and Android support Bluetooth using other
libraries. I'm not sure if non-Linux, non-Android Unices (like FreeBSD)
need another message?
This PR attempts to turn on `-fdiagnostics-color` by default when using
the CMake Ninja generator.
Ninja effectively turns off colored messages by not running subcommands
in a pseudo-terminal. The Ninja maintainers have decided that using
pseudo-terminals has more downsides than upsides, but have helpfully
taught Ninja itself how to parse and remove color codes if its parent
isn't a (pseudo-)terminal.
Colored messages make it easier to read warnings and error messages in a
large build log, and are pretty.
To use it, with a modern LLVM (3.9+), set your CMAKE_PREFIX_PATH
to point to the LLVM install folder or to a LLVM build folder.
We're linking ALL of LLVM libs since I don't really know which ones we need.
LTO will take care of sliming the binary size...
Fixes an issue where Dolphin's revision information could be incorrect
when:
1) CMake was run while HEAD was at commit A
2) HEAD was set to commit B, which didn't have differences from A
that would cause CMake to be re-run
This does not fix the issue with incorrect information about whether
Dolphin was built from a dirty working tree or not.
The built-in `configure_file` command correctly handles the case where
none of the variables change and scmrev.h doesn't need to be rebuilt.
This saves a full re-link of Dolphin any time CMake is re-run.
Lioncash