-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake Refactor #3093
base: master
Are you sure you want to change the base?
CMake Refactor #3093
Conversation
Later, we will provide FindXXXX.cmake files or whatever to do this stuff instead of this wierd Provides hack Only really works with vcpkg for now?
Often these showed up with some libraries that provide their own FindXXXXXX.cmake stuff but were written for versions below 3.5 (which CMake warned about)
This might actually be an A-OK hack, but I don't like it and will eventually just make some custom FindPkg's that provide stuff directly from PkgConfig without all the weird If hacks. This gets it to generate on OpenSUSE for me!
It didn't seem consistent in the ST codebase to add your copyright once you make some changes/refactor stuff, so since there is original code belonging to Christoph, I will remove my own attribution.
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 |
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 |
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 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 |
This function looks similar to find_package, but it also specifies arguments to fallback to PkgConfig, and then external. This is essentially the bulk of all dependency handling, and a weird part of me wonders why it's not actually bundled into CMake (well, the 'external' stuff is definitely done on my own terms) The only thing this doesn't really do is handle the output dependencies of find_package. I'd like to try to alias them all into the 'pkg_target' argument, but we'll see.
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
) |
@@ -106,12 +106,12 @@ For ease of use, here are some installation lines for some Linux distributions: | |||
|
|||
- Ubuntu 18.04/20.04: | |||
``` | |||
sudo apt-get update && sudo apt-get install -y cmake build-essential libogg-dev libvorbis-dev libopenal-dev libsdl2-dev libsdl2-image-dev libfreetype6-dev libraqm-dev libcurl4-openssl-dev libglew-dev libharfbuzz-dev libfribidi-dev libglm-dev zlib1g-dev | |||
sudo apt-get update && sudo apt-get install -y cmake build-essential libogg-dev libvorbis-dev libopenal-dev libsdl2-dev libsdl2-image-dev libfreetype6-dev libraqm-dev libcurl4-openssl-dev libglew-dev libharfbuzz-dev libfribidi-dev libglm-dev zlib1g-dev libfmt-dev libsdl2-ttf-dev libphysfs-dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember to include these packages in the vcpkg example!
Too much overhead for a single function usage
…into nekobro-cmake-refactor
I'm getting a couple errors on OS X (I tried out the branch in a new worktree):
|
x_x
|
Sorry marty im dumb idk what youre doing here this makes 0 sense to me
This still builds on my machine which means my machine is superior. I'm now not sure how we work around weird cases like Vankatas. The only thing that comes to mind is using one of CMake's |
@tobbi |
x_x |
ogg is also installed on my machine. @MatusGuy I think Vankata had a similar issue. There is a regression with the pkg-config stuff (or it never even worked regardless.) I can take a stab at it after work |
Aw snap! Found the issue.
|
Ha, thank you! |
It seems like the fallback modules in external/ are not taken into account. |
That's because we're actually removing them |
@tobbi I think we considered removing SDL2 TTF because we dont believe we needed to maintain a fork. Its a decision we probably shouldn't take lightly, but native builds of sdl2-ttf seem to work fine so far. Can you try building with perhaps a native install of SDL ttf? This should eliminate the error. |
Native SDL_TTF has no support for RAQM for Arabic language suppport. |
#define ST_ASSERT(name, expr) st_assert(__FILE__, __LINE__, name, expr) | ||
|
||
// TODO Make macros for these assert functions to also pass a line number | ||
void st_assert(const std::string_view filename, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think string_view should be passed by reference (even though it's not as expensive as std::string)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
string_view
provides read-only access to an existing string, it does not represent the string itself. Therefore you can pass it as value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recently got a new color printer, so, color me surprised. I didn't know that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I kind of took note with Tobbi on one thing, I dont even need to use string view here. I think I can just use a good old const char* since im just printing the value out.
... because it's not needed. You can find examples and API docs on people using arabic script with sdl2_ttf. Also, is it really worth it to make half-baked arabic language support without supporting RTL first? |
I would really prefer if we tested arabic scripts instead of kinda throwing knives. Lets see if we can live without any custom patches again with visual proof. I'd imagine the team up around SDL2 TTF would actually have such a thing sorted out (i skimmed our fork and it does look like we just applied weird patches overtop of it...), especially since this uses Truetype; i feel like we (me & Marty) are too hasty to conclude on this. |
I think there was an issue with the msi version and components? Weird. Maybe l8er.
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.