ikskuh / SDL.zig

A shallow wrapper around SDL that provides object API and error handling
MIT License
362 stars 80 forks source link

God dammit please add ttf support for windows #160

Open Darkfllame opened 8 months ago

Darkfllame commented 8 months ago

I mean, most of the library paths are already set via the link() function and thus you only need to do as the other systems.

I even have a better idea but I tried and it's annoying, making the zig build file for SDL2 source code, but the original one is like 30k lines or so and not decryptable (for me at least).

Feel free to don't care and continue on the wrapper, but please, as a more "low-level" programmer : I prefer the native module, and would like to get the SDL_ttf library without messing around with zig's build system and modifying your library implementation to do so.

Also add functions for SDL_image and SDL_mixer please :)

ikskuh commented 8 months ago

Just do it, if you need it. I will add functions when i need them, and others do so as well. Just open a PR, and solve the problem instead of being angry. It's faster anyways ;)

jrasanen commented 4 months ago

First and foremost, thanks to Felix for the wrapper; I love it! Second, a comment to the original poster: being angry isn't constructive and helps no one.

I actually got SDL2_ttf working fairly easily with the diff attached below. Note, the diff contains hard-coded paths because I initially just wanted to try out whether it would work at all.

As we need to define the library and include paths for SDL2 TTF, I recommend we create a .build_config/sdl_ttf.json that would contain a structure similar or identical to sdl.json.

Another addition we must have, as far as I know, is to add a linkTtf function that uses std.builtin.LinkMode to determine whether we want static or dynamic linking.

What do you think?

Thanks!

diff --git a/build.zig b/build.zig
index 06b4a24..b1843c9 100644
--- a/build.zig
+++ b/build.zig
@@ -236,7 +236,9 @@ pub fn linkTtf(sdk: *Sdk, exe: *Compile) void {
         // we should rely on the system libraries to "just work"
         exe.linkSystemLibrary("sdl2_ttf");
     } else if (target.result.os.tag == .windows) {
-        @panic("Cannot link TTF on windows yet.");
+        const ttf_include = "C:/dev/libs/SDL2_ttf-2.22.0/x86_64-w64-mingw32/include";
+        exe.addIncludePath(.{ .cwd_relative = ttf_include });
+        exe.addObjectFile(.{ .cwd_relative = "C:/dev/libs/SDL2_ttf-2.22.0/x86_64-w64-mingw32/lib/libSDL2_ttf.dll.a" });
     } else if (target.result.isDarwin()) {
         if (!host_system.os.tag.isDarwin())
             @panic("Cannot cross-compile with TTF to macOS yet.");
ikskuh commented 4 months ago

I had another idea: we can basically use the package manager now to depend on the official release binaries and just fetch them as needed, so you literally just tell the library: please link sdl2 / sdl2_image / sdl2_ttf for windows and we can then fetch the required files and paths via lazy dependencies

jrasanen commented 4 months ago

we can basically use the package manager now to depend on the official release binaries and just fetch them as needed, so you literally just tell the library: please link sdl2 / sdl2_image / sdl2_ttf for windows and we can then fetch the required files and paths via lazy dependencies

This sounds like an interesting idea. Maybe this could be a separate issue? This would increase the ergonomics. But even with this, it would still be nice to be able to override the library.