Open swagtoy opened 3 weeks ago
I hacked PkgConfig to work for just my system temporarily (as CMake files for many libraries actually already exist, except for Ogg which seemed finnicky), but how should I tackle find_package for non-existant things and then external
being used as a fallback? I guess I could provide my own FindXXXXX.cmake files? OR what about those XXXX-config.cmake
files?
My suggestion would be to only support vcpkg but if you really need that you can use the XXX_FOUND variable to check if the find package command was successful.
I guess a modified FindXXXX.cmake could work. Basically the better ProvideXXXX.cmake
My suggestion would be to only support vcpkg but if you really need that you can use the XXX_FOUND variable to check if the find package command was successful.
Well, I'm building on Linux now, and find_package actually works for that too (for most things). If you take a look at your Linux /usr/lib{64,}/cmake directory you will find a ton of libraries that provide CMakefiles, as well as /usr/share/cmake which has some more generic ones for stuff like CURL and all that.
But I think I can do a fallback for if a package doesn't get found, then use pkg_config, then use external/asdfghjk.
Even better than custom FindXXXX.cmake files, I could even write a fancy macro like add_package
, which basically does what the Ogg hack does, but it takes more arguments such as the pkg-config fallback packages, as well as an external directory if it exists. Then, for example, say that the CMake files provided break on someones system (but they DO exist), we could have a setting you could pass to just prefer external or prefer PkgConfig).
The macro would accomplish this without duplicating a lot of files, I think.
You should 100% support pkg config but if you do you should add an option to disable it because if i recall correctly @mrkubax10 would want that? Also its just handy in general.
pkgconfig will generally speaking be a fallback option if a FindXXXX.cmake doesn't exist in the System cmake directory, but again; using a macro, I could probably have some variables to basically ignore the pkg-config fallback
A quick reference for anyone curious about the add_package command, it's very similar to the find_package command, but you can also specify the Provides files (not implemented as of typing this) or the PkgConfig fallbacks. It essentially lets me define a package in one line.
EX:
add_package(SDL2 # <-- the "output" target
PKG SDL2 # <-- The find_package package, in this case it gets SDL2 (might look similar to the "output" target)
CONFIG # <-- (optional) Passed to find_package if its a CONFIG
REQUIRED # <-- (optional) NOT passed to find_package, just a check to throw an error if nothing is found
PKG_CONFIG sdl2 sdl2_ttf # <-- (optional, recommended) List of packages for PkgConfig
PROVIDES ProvideSDL2 # <-- (optional) Fallback to just look at the provided file. Undecided if I should fall back to a FindXXXX.cmake yet
)
I'm gonna test mingw on this
The doors are open to anyone willing to test this monstrosity :) I've mostly been testing on Windows, but I got a successful build on OpenSUSE a while back. Haven't tested anything there.
Need macOS testers before merging plox
Test cases still need to be finished. In-game runtime tests will be done in a separate PR. I've discussed a tiny bit on what "in-game runtime tests" are, but essentially a special menu you get when running (and compiling) the game with --game-tests
or in debug mode + NDEBUG defined.
This is a PR that tries to refactor the
CMakeFiles.txt
, splitting some things into other files, cleaning up the "Provides" nonsense, and... making the game actually build.For example:
libphysfs
requires manually copying the DLL on Windows (as well on Linux), but I've personally had linking issues on OpenSUSE. I've unfortunately just never succeeded in building this game.It was planned to be a rewrite, and it kind of is, but it's mostly just axing stuff from the current files. It will need plenty of testing.
TODO
Supertux2_lib
andSupertux2_c
external
stuff when neededIt
(will soon)also removes theSupertux_lib
split, making the tests instead depend on the specific files being tested, as well as using CMake's built-in testing functionality instead of GoogleTest.