Builds were failing when built-from-source versions of SDL2 libraries were used. This is because building from scratch delivers the libraries to /usr/local instead of the system-managed libraries in /usr. This fix for this is 2-fold.
Next, we make sure that build dependencies expected to be system-level (not vendored or included in this repo) are included with -isystem instead of -I. We also make sure that any /usr/local paths appear to the left of any /usr paths, since the search goes left to right.
I'm hoping these changes work on other systems as well, and I consolidated the call to target_include_directories for both Windows and Linux. I didn't see a reason they should be different, unless the SYSTEM argument causes problems on Windows. I also included custom *.cmake files for both SDL2_image and SDL2_ttf, since I believe that neither are included in the standard CMake distributions.
Builds were failing when built-from-source versions of SDL2 libraries were used. This is because building from scratch delivers the libraries to
/usr/localinstead of the system-managed libraries in/usr. This fix for this is 2-fold.First, we make sure the CMake can properly look up system configurations. This is done by custom
*.cmakefiles committed to this repo, as per this advice: https://trenki2.github.io/blog/2017/07/04/using-sdl2-image-with-cmake/Next, we make sure that build dependencies expected to be system-level (not vendored or included in this repo) are included with
-isysteminstead of-I. We also make sure that any/usr/localpaths appear to the left of any/usrpaths, since the search goes left to right.I'm hoping these changes work on other systems as well, and I consolidated the call to
target_include_directoriesfor both Windows and Linux. I didn't see a reason they should be different, unless theSYSTEMargument causes problems on Windows. I also included custom*.cmakefiles for both SDL2_image and SDL2_ttf, since I believe that neither are included in the standard CMake distributions.