libmach: initial API bindings for mach core #406

2022-07-13T05:02:07Z

zack466 commented

2022-07-13 05:02:07 +00:00

(Migrated from github.com)

This pull request includes:

C API bindings for Core Mach, exported from src/bindings.zig
Changes to build.zig in order to build libmach
Test programs located in libmach/ to check if libmach works as expected

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 pull request includes: 1. C API bindings for Core Mach, exported from `src/bindings.zig` 2. Changes to `build.zig` in order to build `libmach` 3. Test programs located in `libmach/` to check if `libmach` works as expected - [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) approved these changes

2022-07-15 05:22:29 +00:00

emidoots (Migrated from github.com) left a comment

This looks like a great starting point, and is a clear improvement over what we have here today so I'm going to merge it. We can continue to iterate on this. I'll leave feedback inline on how we can improve it next

emidoots (Migrated from github.com) reviewed

2022-07-15 05:23:48 +00:00

src/bindings.zig

					
				@ -0,0 +33,4 @@

				        return;

				    }

				    if (libmach.core_callbacks.core_update == null) {

				        std.debug.print("Did not provide a core_update callback\n", .{});

Perhaps we should panic in these cases?

emidoots (Migrated from github.com) reviewed

2022-07-15 05:39:43 +00:00

src/bindings.zig

					
				@ -0,0 +1,52 @@

				const std = @import("std");

Two thoughts for improvement:

Should these bindings live here, or in libmach I wonder? The same question would go for other Mach libraries in the future, e.g. when we expose a C ABI for the ECS library, I wonder where it should live?
We should plan on changing this API to reflect what Ayush said in Matrix, something like this as our long-term goal (but may require some changes to make this possible):

int main(void) {
    mach_platform_init(init_fn, usr_ptr);
    while (...) {
        mach_platform_update(update_fn, resize_fn, usr_ptr);
    }
    mach_platform_deinit(deinit_fn, usr_ptr);
}

Two thoughts for improvement: 1. Should these bindings live here, or in `libmach` I wonder? The same question would go for other Mach libraries in the future, e.g. when we expose a C ABI for the ECS library, I wonder where it should live? 2. We should plan on changing this API to reflect what Ayush said in Matrix, something like this as our long-term goal (but may require some changes to make this possible): ``` int main(void) { mach_platform_init(init_fn, usr_ptr); while (...) { mach_platform_update(update_fn, resize_fn, usr_ptr); } mach_platform_deinit(deinit_fn, usr_ptr); } ```

emidoots (Migrated from github.com) reviewed

2022-07-15 05:42:29 +00:00

src/bindings.zig

					
				@ -0,0 +7,4 @@

				// Current Limitations:

				// 1. Currently, ecs seems to be using some weird compile-time type trickery, so I'm not exactly sure how

				// `engine` should be integrated into the C API

				// 2. Core might need to expose more state so more API functions can be exposed (for example, the WebGPU API)

Once https://github.com/hexops/mach/pull/403 lands we should end up being ABI-compatible with the webgpu.h API, and Zig's stage2 compiler could even emit webgpu.h for us based on this too I think. Should be possible to start writing Mach core / WebGPU apps using this.

Once https://github.com/hexops/mach/pull/403 lands we should end up being ABI-compatible with the `webgpu.h` API, and Zig's stage2 compiler could even emit `webgpu.h` for us based on this too I think. Should be possible to start writing Mach core / WebGPU apps using this.

emidoots (Migrated from github.com) reviewed

2022-07-15 05:43:50 +00:00

libmach/test.lisp

					
				@ -0,0 +1,64 @@

				;; Tests the behavior of `libmach` using Common Lisp's CFFI

Just curious @zack466 which language do you actually plan to use this from? I've personally never used lisp, but would be interested in maintaining some official Go bindings potentially.

iddev5 (Migrated from github.com) reviewed

2022-07-15 07:18:27 +00:00

src/bindings.zig

					
				@ -0,0 +1,52 @@

				const std = @import("std");

My opinion on (1) I think the bindings should live inside src/ maybe changing the name to libmach.zig to be more clear. The libmach directory currently doesn't serves any purpose, it just contains examples.

zack466 (Migrated from github.com) reviewed

2022-07-15 17:39:52 +00:00

src/bindings.zig

					
				@ -0,0 +1,52 @@

				const std = @import("std");

Well, right now build.zig is set to output the libmach shared library to libmach/build/. Is there another location we would want it to go? (or should we just keep it in zig-out/lib/).

For the location of the bindings, I think it would have to be in src so it has easy access to mach internals. If it were in libmach we would have to import mach, which would probably be annoying to deal with (in terms of build scripts and stuff).

Also, currently the libmach code is split between src/bindings.zig and src/platform/libmach.zig. I did this since Zig was not letting me import Core from ../Core.zig in src/platform/libmach.zig, so I couldn't put all of the code in that file. But looking at how wasm.zig is handled (which imports ../Core.zig without any problems), I realize that we can probably just merge all of the code into src/platform/libmach.zig.

Well, right now `build.zig` is set to output the `libmach` shared library to `libmach/build/`. Is there another location we would want it to go? (or should we just keep it in `zig-out/lib/`). For the location of the bindings, I think it would have to be in `src` so it has easy access to mach internals. If it were in `libmach` we would have to import `mach`, which would probably be annoying to deal with (in terms of build scripts and stuff). Also, currently the libmach code is split between `src/bindings.zig` and `src/platform/libmach.zig`. I did this since Zig was not letting me import Core from `../Core.zig` in `src/platform/libmach.zig`, so I couldn't put all of the code in that file. But looking at how `wasm.zig` is handled (which imports `../Core.zig` without any problems), I realize that we can probably just merge all of the code into `src/platform/libmach.zig`.

zack466 (Migrated from github.com) reviewed

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

libmach/test.lisp

					
				@ -0,0 +1,64 @@

				;; Tests the behavior of `libmach` using Common Lisp's CFFI

Common Lisp, haha

CFFI code is dead simple in Lisp (as you can see in test.lisp), which is really nice. I was actually originally trying to work with bgfx, but it was a huge pain to compile and use properly, so I eventually gave up. With Mach, on the other hand, a simple zig build does the trick!

Common Lisp, haha CFFI code is dead simple in Lisp (as you can see in `test.lisp`), which is really nice. I was actually originally trying to work with bgfx, but it was a huge pain to compile and use properly, so I eventually gave up. With Mach, on the other hand, a simple `zig build` does the trick!

Sign in to join this conversation.

No reviewers

emidoots