glfw: add shared option which builds glfw into it's own shared library #442

Merged

kcbanner merged 3 commits from feature_glfw_shared into main

2022-07-31 20:56:13 +00:00

kcbanner commented

2022-07-31 18:04:00 +00:00

(Migrated from github.com)

This adds the shared option, which builds GLFW into it's own shared library.

The use case for this is as follows (in this setup, the exe loads the game dll at runtime using std.DynLib):

    // Engine launcher
    const exe = b.addExecutable("ion", "src/main.zig");
    {
         ... setup the exe build step ...
        exe.addPackage(glfw.pkg);
        glfw.link(b, exe, .{
            .shared = true
        });
    }

    // Game dll
    const game = b.addSharedLibrary("game", "game/src/game.zig", .unversioned);
    {
        ... setup the game build step ...
        game.addPackage(glfw.pkg);
        glfw.link(b, game, .{
            .shared = true
        });
    }

This way, both game and exe link with the shared library, so that there is one copy of the _glfw global state in the process. Static linking wouldn't work here, as the dll and exe would have separate copies of _glfw.

A couple things I'm not sure about:

I opted to cache the shared library for each call (create it on the first glfw.link call and re-used the instance across calls). The other option would be a separate call (ie. glfw.createSharedGlfw) to create the shared lib, and you'd pass that as the option instead of a bool. I'm happy to change over to that, but I was trying to keep the API simple.
Specifying zig-out/bin as the output dir - this works in the simple case, but may break if that directory has been changed on the parent step. The intention is to place the dll next to whatever exe/dll is linking with it, but I'm not familiar enough with the build system to know how to get that automatically.
By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

This adds the `shared` option, which builds GLFW into it's own shared library. The use case for this is as follows (in this setup, the exe loads the game dll at runtime using std.DynLib): ``` // Engine launcher const exe = b.addExecutable("ion", "src/main.zig"); { ... setup the exe build step ... exe.addPackage(glfw.pkg); glfw.link(b, exe, .{ .shared = true }); } // Game dll const game = b.addSharedLibrary("game", "game/src/game.zig", .unversioned); { ... setup the game build step ... game.addPackage(glfw.pkg); glfw.link(b, game, .{ .shared = true }); } ``` This way, both `game` and `exe` link with the shared library, so that there is one copy of the `_glfw` global state in the process. Static linking wouldn't work here, as the dll and exe would have separate copies of `_glfw`. A couple things I'm not sure about: - I opted to cache the shared library for each call (create it on the first `glfw.link` call and re-used the instance across calls). The other option would be a separate call (ie. `glfw.createSharedGlfw`) to create the shared lib, and you'd pass *that* as the option instead of a bool. I'm happy to change over to that, but I was trying to keep the API simple. - Specifying `zig-out/bin` as the output dir - this works in the simple case, but may break if that directory has been changed on the parent step. The intention is to place the dll next to whatever exe/dll is linking with it, but I'm not familiar enough with the build system to know how to get that automatically. - [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

emidoots (Migrated from github.com) reviewed

2022-07-31 18:08:03 +00:00

glfw/build.zig

Could you leave this function signature as it was before, so that e.g. this does not break - and instead introduce a new private fn testStepShared & just duplicate the code here to test the shared library approach?

Could you leave this function signature as it was before, so that e.g. [this does not break](https://github.com/hexops/mach/blob/e6d7faaabab303d006ea998547c6dc7ce2305c2a/build.zig#L33) - and instead introduce a new private `fn testStepShared` & just duplicate the code here to test the shared library approach?

alichraghi (Migrated from github.com) reviewed

2022-07-31 18:11:02 +00:00

glfw/build.zig

i think this is a good approach and should be applied to all sub-projects

emidoots (Migrated from github.com) reviewed

2022-07-31 20:14:00 +00:00

glfw/build.zig

not opposed to that, let's do it in another PR though.

emidoots commented

2022-07-31 20:16:40 +00:00

(Migrated from github.com)

@kcbanner I pushed a few changes / cleanups, give this a try and let me know if it still works for you?

I also removed the line that was writing the lib into the bin dir, instead opting for the natural Zig output location so we end up with e.g.:

zig-out
zig-out/bin
zig-out/bin/glfw_tests
zig-out/bin/glfw_tests_shared
zig-out/lib
zig-out/lib/libglfw.dylib

@kcbanner I pushed a few changes / cleanups, give this a try and let me know if it still works for you? I also removed the line that was writing the lib into the bin dir, instead opting for the natural Zig output location so we end up with e.g.: ``` zig-out zig-out/bin zig-out/bin/glfw_tests zig-out/bin/glfw_tests_shared zig-out/lib zig-out/lib/libglfw.dylib ```