* CMake: use PROJECT_VERSION instead of solvespace_*_VERSION
In 006539b, solvespace_MAJOR_VERSION etc. were removed.
However, these variables were still referenced in some places.
Solution: Use PROJECT_VERSION instead.
* CMake: re-add link directories for solvespace target
006539b removed the call to link_directories for gtkmm, jsonc & fontconfig.
This leads to linking errors if those libraries are in "non-standard"
paths.
Fix this by introducing a target specific target_link_directories call.
Fixes#1173
* snap: port to core20 & adapt to CMake changes
Moving to core20 was long overdue anyway, and
the recent CMake changes necessitated some fixes.
Also switch to LZO compression for (way) better cold start
performance.
This commit performs two main changes:
* Alters the shaders to use only strictly conformant GLSL 2.0.
* Alters the Windows UI to use ANGLE via GL ES 2.0 and EGL 1.4.
This commit also drops official support for Windows XP, since ANGLE
requires a non-XP toolset to build. It is still possible to build
SolveSpace for Windows XP using:
cmake -T v120_xp -DOPENGL=1
This commit makes common external packages always be included through
find_package to eliminate differences in variables set, wraps
find_package for vendored libraries on Windows to factor out common
code, and removes miscellaneous useless code elsewhere in dependency
handling.
This also fixes a problem where pkg-config would pick up `build`
libraries instead of `host` when cross-compiling.
After this change, SolveSpace does not contain nonfree assets.
Additionally, Perl is not required for the build.
Note that in the US, case law suggests that copyright does
not apply to bitmap fonts:
http://www.renpy.org/wiki/renpy/misc/Bitmap_Fonts_and_Copyright
Nevertheless, it was prudent to replace the asset with something
that is unambiguously free.
As a side effect, zlib and libpng are now git submodules,
based on their respective official git repositories.
This is necessary, because MinGW has a different ABI and
it cannot use the prebuilt binaries built by MSVC.
The submodules are also used for Windows, for several reasons:
* to allow 64-bit builds;
* to allow using newer MSVC, which doesn't like the prebuilt
libraries;
* to keep the libraries updated.
Maximilian Federle
Ryan Pavlik
Koen Schmeets
whitequark
luzpaz