Changes to support generating the sokol-fetch bindings in zig

[trace-andreason]

Related to this issue: floooh/sokol-zig#63. Not ready to be merged, just thought it might be helpful for that discussion

[floooh]

...that fetch callback should actually be handled here:

sokol/bindgen/gen_zig.py

Lines 339 to 340 in f70cc07

	elif util.is_func_ptr(field_type):
	l(f" {field_name}: ?*const fn ({funcptr_args_c(field_type, prefix)}) callconv(.C) {funcptr_result_c(field_type)} = null,")

...I'm currently investigating why it isn't...

[floooh]

Aha, because it's a typedef in the sokol_fetch.h header, and that's not detected in the bindings generation script.

If I remove the sfetch_callback_t typedef from sokol_fetch.h and replace the callback declaration in sfetch_request_t to this:

typedef struct sfetch_request_t {
    ...
    void (*callback) (const sfetch_response_t*);
    ...
} sfetch_request_t;

...it works, and generates the following Zig struct:

pub const Request = extern struct {
    channel: u32 = 0,
    path: [*c]const u8 = null,
    callback: ?*const fn ([*c]const Response) callconv(.C) void = null,
    chunk_size: u32 = 0,
    buffer: Range = .{},
    user_data: Range = .{},
};

...can you integrate this sokol_fetch.h change in your PR and remove your "manual exception hack"?

[trace-andreason]

yep, sounds good! Are you cool with these overloaded names?

    'sfetch_continue':                      'fetch_continue', # 'fetch' is reserved in Zig
    'sfetch_desc':                          'description'     # 'desc' shadowed by earlier definiton

fetch_continue might be weird because it'll probably end up being fetch.fetch_continue() in zig...

[trace-andreason]

made those changes

[floooh]

...for the sfetch_desc override I would actually prefer sfetch_get_desc which would then end up as fetch.getDesc() on the Zig side.

For continue maybe resume? Since it's "resuming from paused state".

...tbh, sfetch_resume() would also be a good change in the C header.

[floooh]

...one other change I'd like is to restrict sokol_fetch.h to the Zig bindings for now, e.g. remove the sokol_fetch item from the tasks array in gen_all.py, and instead do this down in the gen_zig block:

zig_tasks = [
    *tasks,
    [ '../sokol_fetch.h', 'sfetch_', [] ],
]
for task in zig_tasks:
   ...

...should have recommended this from the start but didn't think of the other language bindings...

[trace-andreason]

turns out resume is also reserved

[trace-andreason]

So I'll give you my 2 cents on naming here, coming from a beginner and copying examples written in C to zig. If we made continue be continue_fetching or something that starts with continue, you will at least get some editor help when just typing in the name of the c function.

[trace-andreason]

I went ahead and named it continue_fetching, but open to any other suggestion. All other comments are incorporated.

[floooh]

Yeah continue_fetching is fine :)

[trace-andreason]

bindings build step is going to fail until sokol_fetch.c file is added to the repo

[floooh]

Yep, I think I can take over from here. I'll also need to do a quick check if the dropped typedef breaks anything (I don't think so, but technically it's a breaking change). I'll try to look into it later today.

[floooh]

Zig master might have had a breaking change in LazyPath. I'm looking into it.

PS: yep, I'll check what's needed to fix sokol-zig (and park the current zig-0.12.0 compatible version in a branch)

[floooh]

Ok, took a bit longer then I had hoped, but the sokol-zig build.zig is now fixed for the current zig head version.

PS: the new D bindings suffer from the same problem because that also uses Zig as build system, but let's ignore that for now ;)

[floooh]

I'll go ahead and merge this PR.

The next step would then be in sokol-zig again to add the C source file to build.zig here:

https://github.com/floooh/sokol-zig/blob/7d569775df73d1e869a1df12dfc647e56c7cb77a/build.zig#L265

...and the fetch.zig module here:

https://github.com/floooh/sokol-zig/blob/7d569775df73d1e869a1df12dfc647e56c7cb77a/src/sokol/sokol.zig#L9

Ideally we would also have a new sample, but I can do that at a later time.

[floooh]

...also added a little blurb to the CHANGELOG about the theoretically breaking change in sokol_fetch.h

[trace-andreason]

next steps for sokol-zig: https://github.com/floooh/sokol-zig/pull/67/files