The CMake Windows build was broken because of me adding a usage
of std::codecvt_utf8_utf16 to StringUtil.cpp. Kinda silly to have
a warning for an API with no standard replacement available...
All supported platforms now have easy access to a compiler with C++17
support.
C++17 potentially allows for some nice cleanups and removes the need
for standard library backports (optional/variant).
See discussion at https://dolp.in/pr6264#discussion_r158134178
This macro (that has unfortunately become the de-facto way of
introducing targets) has a lot of disadvantages that outweigh the fact
that you avoid writing two extra lines of CMake script.
- It encourages the use of variables. In a build system the last thing
we want to care about is mutable state that can be avoided.
- It only handles linking in the libraries and nothing else. It's a
laziness macro.
- We should be explicit about what we're doing by introducing the target
first, not last.
This gets the ball rolling by migrating Core off the macro. Note that
this is essentially 1-to-1 unrolling of the macro, therefore we're
still linking in all libraries as public, even though that may not be
necessary.
This can be revisited once everything is off the macro for a quicker
transition period.
Some toolchains provide enough of C++17 to conflict with Dolphin's
included backport of std::variant and std::optional. Specifically,
the recently-released macOS 10.13 SDK does not provide the <optional>
or <variant> headers, but does provide `in_place_t` in the <utility>
header.
std::optional makes a few things a bit neater and less error prone.
However, we still cannot use C++17 (unfortunately), so this commit
adds an implementation of std::optional that we can use right now.
Based on https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/lib/gtl/optional.h
which seems to be fairly similar to C++17's <optional> and standards
compliant. It's one of the few implementations that handle propagating
type traits like copy constructibility, just like libc++/libstdc++.
Compilers are very picky and don't use PCH when they have been compiled
with different flags. I even got some ICE in MSVC, so removing them for now.
Modules are the solution.
These directories have been unused for several years and without any automated
way of running the tests, they are pretty much useless.
While they might be useful as a reference, in their present state they should
not be kept in the repository.
Also, don't check to see if a directory is a wad file. They aren't. This removes an annoying and invalid debug assertion with the debug build.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7682 8ced0084-cf51-0410-be5f-012b33b47a6e
Some notes about this:
- config.h doesn't get written yet, so you'll have to use one generated by SCons
- dependency checking isn't really implemented, yet. Just some basic checks for OpenGL or ALSA, we need something more sophisticated though.
- the OpenGL plugin fails to load for some reason which I can't debug right now due to the libc debuginfo package version in openSUSE not matching the runtime packages
- there's even some support for generating install packages (rpm/deb/.. packages, NSIS installer, etc). It doesn't work properly right now though, since some paths seem to be hardcoded into Dolphin's source
- probably lots of other stuff I forgot... Just take a look at all the TODOs in the CMakeLists.txt files for more information ;P
Additionally, I added various files to the svn:ignore list.
tl;dr: Unless you are a dev or you're building binary packages, this commit shouldn't bother you :P
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6326 8ced0084-cf51-0410-be5f-012b33b47a6e
JosJuice