Add CMake build support

[FtZPetruska]

Thie PR adds support for building with CMake (See #18). It is based on the existing scons script for files and flags used.

The CMake script includes:

• Generation of CMake package files so the library can be used in other CMake projects by using find_package(libgambatte)
• Generation of a pkg-config file, so the library can be used in non-CMake projects by using pkg-config --cflags --libs libgambatte
• Building both the static and shared libraries at the same time.
• Support for the testrunner.

There were a few code changes, mainly aiming at making building and installing more convenient:

• Move newstate.h to the public headers, since gambatte.h depends on it, it should be public too
• Instead of passing -DHAVE_X, prefer generating a config.h. This is necessary as gbint.h needs to know which of cstdint or stdint.h are available, but that information would be lost for a consumer of the library.
• Edit the scons script to generate its own config.h, so the shell scripts keep working for the time being

The CI script has been completely reworked:

• Run on Ubuntu, macOS, Msys2 (ucrt-x86_64, i686), Windows (clang-cl, clang)
• Run the test runner
• Test the CMake package (from an install and from the build directory)
• Test the pkg-config file

Lastly, the README.md and INSTALL.md have been updated to remove the references to Qt, use CMake, and cover more common Linux distributions. Fixes #5

---

A few additional notes:

• the macOS CI environment struggles to get the correct libpng (even specifying its prefix manually), so instead PNG_LIBRARY and PNG_PNG_INCLUDE_DIR are set manually to help the Find module. Causes the tests to SEGFAULT otherwise.
• MSVC currently does NOT work, there is a VLA in src/statesaver.cpp:553 that breaks compilation. It is probably not a difficult fix, but this PR is already big enough as-is, and there may be more issues.

[CasualPokePlayer]

Perhaps we should consider making snes_spc a separate "library" in this regard instead of bundled into libgambatte (not really any different in practice since it'd always just a static library included in libgambatte). Although that's probably suited for a later time.

[FtZPetruska]

Regarding symbols visibility, as it stood, the public API (gambatte.h) was not available when linking against the DLL.

On the other hand, the cinterface.cpp file explicitly exported functions despite them not be declared in any header.

To address that, I made the following changes in 4ea626a:

• Made a public gbexport.h header that defines a GBEXPORT macro similar to what was defined in cinterface.h, with the GCC/Clang equivalent.
• Exported every class/function declared in the public headers
• Switch the Linux/macOS behaviour to match what Windows does (symbols hidden by default), this has the side-effect of slightly reducing the binary size too.
• The cinterface.cpp file was left "as-is" for backwards compatibility. Since the GBEXPORT macro no longer contains the extern "C" part, it was added explicitly around these functions.

This change makes the shared library usable on Windows as previously programs such as the testrunner would fail to link dynamically.

[CasualPokePlayer]

Is this GBEXPORT on classes behavior for if you're using a shared library yet you're using the C++ API? You shouldn't be using that API directly in such a case, as that usually will end up resulting in linking errors and trying to dynamically link with dlopen/LoadLibrary would not exactly be fun to do (both due to compiler specific name mangling and potentially even other compiler specific ABI differences). You should only be using the C++ API if you're using the library as a static library (and you are in fact a C++ user and using the same compiler here).

To properly address the issue of a lack of a header, function declarations should just be added to cinterface.h (or whatever it's named now) for the cinterface.cpp functions. Programs such as the testrunner shouldn't be dynamically linking anyways (those statically link unless something changed in this PR), so something is going wrong much earlier there.

[FtZPetruska]

Just to make sure I get this correctly:

• We do not want the C++ API to be exported (gambatte::GB/NewState*/PakInfo classes), these constructs should only be usable from a static library.
• When using the shared library, only the functions defined in cinterface.cpp should be accessible.

To properly address the issue of a lack of a header, function declarations should just be added to cinterface.h (or whatever it's named now) for the cinterface.cpp functions.

I am thinking about making it a gambatte-c.h header, and add the prototypes for the functions defines currently in cinterface.cpp. I think it may desirable to also build these functions in the static library, so they are always available regardless of the library type (in scons, cinterface.cpp was only included in shared builds).

Programs such as the testrunner shouldn't be dynamically linking anyways

I had made the static library a requirement to run the test:

if(NOT LIBGAMBATTE_BUILD_STATIC)
  message(FATAL_ERROR "Building the static library is required to run tests")
endif()

But it's good to know that you are not supposed to dynamically link it.

[CasualPokePlayer]

Since this might be expected to be #included from a C context (not C++), it may be better to #ifdef this around __cplusplus.

Similarly, instead of #including gambatte.h or newstate.h, it may be better to just forward declare struct GB instead, (and other redeclarations from the gambatte namespace as that might not be available in a C context), at the very least do that when __cplusplus is not defined.

[CasualPokePlayer]

If this is used by the user of a dll rather than the dll itself, then dllexport would be incorrect, dllimport is the correct declspec (and I don't think visibility attribrute is correct either for non-Windows cases, rather it should just be extern)

[FtZPetruska]

Checking GCC's documentation on visibility, you're correct about the dllexport/dllimport.

According to that same documentation, for the non-Windows case, __attribute__((visibility("default"))) seems to indicate both export and import.

[FtZPetruska]

Seems like the change in d1ae9ec broke CI.

Looking around, other projects such as SDL seem to only be using dllexport.

[CasualPokePlayer]

Breaking CI likely indicates it got used internally in the library, or it got used when linking it in statically. You can only use dllimport when you are a user of the library (so not the library itself) and the library is a dll (if it's static, you don't use dllimport/dllexport).

[CasualPokePlayer]

extern "C" here is a bit interesting, technically this is correct, although in practice it typically doesn't actually matter, as most (if not all practical) C++ implementations wouldn't have any issues with a C++ linkage function being assigned to a C linkage function pointer and vice versa (as they function the same at runtime), although this isn't actually guaranteed by the standard (C++ linkage could entail a different calling convention compared to the same function being assigned C linkage, in practice this never occurs).

On that, technically this is not correctly handled in gambatte.h as they all would use C++ (default) linkage, so if we want that to be ""correctly"" done, all those callback definitions need extern "C".

[FtZPetruska]

On the off chance that there is a compiler out there that defaults to using a different calling convention between C and C++, I went ahead and declared the other function prototypes as extern "C" for consistency.

Moreover, to make sure the C API is actually usable from C, I added a simple test in c75fe83 that creates and deletes a GB object using the C API.