add IMGUI support

[kassane]

fix #10

old branch, need long rebase... I'll delete (for testing only)
https://github.com/kassane/sokol-d/tree/imgui-support

inspired by:

• Prepare inclusion of sokol_imgui.h into sokol-zig bindings. floooh/sokol-zig#69
• Make the custom Emscripten SDK build steps more 'idiomatic' floooh/sokol-zig#70

[kassane]

Need cimgui binding for run example. Old module amalgamation cimgui + sokol_imgui:
https://github.com/kassane/sokol-d/blob/1d1fc586969aba82fc6b854aeb2d16f7ec656976/src/sokol/imgui.d

now, only sokol_imgui:

sokol-d/src/examples/imgui.d

Lines 103 to 115 in 1110006

	// -- CIMGUI -- //
	extern (C)
	struct ImVec2
	{
	float x = 0.0f;
	float y = 0.0f;
	}
	extern (C) bool igBegin(const(char)* name, bool* p_open, ImGuiWindowFlags flags);
	extern (C) void igEnd();
	extern (C) void igSetNextWindowPos(const ImVec2 pos, ImGuiCond cond, const ImVec2 pivot);
	extern (C) void igSetNextWindowSize(const ImVec2 size, ImGuiCond cond);
	extern (C) bool igColorEdit3(const(char)* label, ref float[3] col, ImGuiColorEditFlags flags);

[kassane]

Some questions (for zig-dev)

What would you add cimgui to the example?

Unlike zig translate-c, importC doesn't read header, only C source.
However, this still falls short (translate-c also has some issues). The only difference between the two projects is the level of support (zig project wins here).

More info - commands

Zig translate-c has the ability to convert all the code (declaration + implementation), importC just the declaration (equivalent to rust-bindgen or sokol_gen).

# zig
$ zig translate-c <flags> -cflags <c-flags> -- <C source> -lc
# D
$ ldmd2/ldc2 <flags> <C source> -Hf=<D interface source> (*.di)
# zig have inside clang,
# ldc2 need call cc (system compiler) - like rustc.
# But -gcc=(custom CC) is used only C source and -linker=(custom LD) or -link-internally (inside lld, like zig) any object (w/o C source) 
# and rustc equivalence is -linker= flag.

And not have current D module about cimgui, only old imgui (C++, no extern(C)) version.

[kassane]

Please, @floooh.

Test it!

Preview

• Linux (native):
  

• Wasm32/Firefox:
  

Note: For wasm32 build change...

sokol-d/build.zig

Line 245 in 8d589cb

if (!opt_with_sokol_imgui or target.result.isWasm())

Why block? CI error. Why imgui-cpp need assert.h, but rebuild (no-clean global cache) works!

And for old ldc2 versions (1.36...1.38 [latest]) change... .freestanding to .emscripten or try ldc2-master

sokol-d/build.zig

Lines 512 to 515 in 8d589cb

	else if (options.target.result.isWasm() and options.target.result.os.tag == .freestanding)
	b.fmt("{s}-unknown-unknown-wasm", .{@tagName(options.target.result.cpu.arch)})
	else if (options.target.result.isWasm())
	b.fmt("{s}-unknown-{s}", .{ @tagName(options.target.result.cpu.arch), @tagName(options.target.result.os.tag) })

[floooh]

Note that there was an bug in the translateC step in the cimgui sample which caused this above error about missing assert.h in imgui.h when trying to build for wasm32-emscripten. I fixed this by always running the translateC step with the host target (instead of the build target):

https://github.com/floooh/sokol-zig-imgui-sample/blob/b2fd57bc0ddc406fc3a66160fa37ca27842ad127/deps/cimgui/build.zig#L51

...otherwise I would somehow need to inject the Emscripten include path into the translateC step. Using the host triplet is the better solution though, since there no platform-specific stuff happening in the translateC step.

[kassane]

Note that there was an bug in the translateC step in the cimgui sample which caused this above error about missing assert.h in imgui.h when trying to build for wasm32-emscripten. I fixed this by always running the translateC step with the host target [...]

According to this solution, perhaps it would have been possible to use importC to bypass the error, just like translate-c.
However, the assert.h error occurs during the libsokol build, a step before ldc2.
I know there exists a step wait for emsdk_setup in libsokol and this will run imgui in a direct dependency.

sokol-d/build.zig

Lines 79 to 82 in 20fe32c

	// one-time setup of Emscripten SDK
	if (try emSdkSetupStep(b, options.emsdk.?)) |emsdk_setup| {
	lib.step.dependOn(&emsdk_setup.step);
	}

sokol-d/build.zig

Lines 184 to 194 in 20fe32c

	if (options.with_sokol_imgui) {
	lib.addCSourceFile(.{
	.file = b.path(csrc_root ++ "sokol_imgui.c"),
	.flags = cflags,
	});
	const cimgui = try buildImgui(b, lib);
	for (cimgui.root_module.include_dirs.items) |dir| {
	try lib.root_module.include_dirs.append(b.allocator, dir);
	}
	lib.linkLibrary(cimgui);
	}

---

Another question that puzzles me. Would it be useful to use the build.zig dependency to make sokol-zig a dependency of sokol-d?
That way we could reduce the complexity redundancy of build.zig.

[kassane]

@floooh , my assert.h fix - if with_imgui enabled, move lib.step.dependOn(&emsdk_setup.step); to libimgui.step.dependOn(&emsdk_setup.step);
bca71be

[floooh]

Ah btw, I fixed this a bit differently, by letting the cimgui library depend on the sokol C library (up in the top level project):

https://github.com/floooh/sokol-zig-imgui-sample/blob/87d703e2f1f43135a5a5e9bfc2a56910d48b7e7b/build.zig#L69-L73

Since the sokol C library depends on the Emscripten SDK setup this also guarantees that the SDK is setup when cimgui is compiled (e.g. the idea is that all C libraries need to depend on the sokol C library... but maybe this could indeed be moved up into sokol-zig since we're iterating over the C libraries anyway in the linker step - also the injection of the Emscripten include path... hmm...)

Another question that puzzles me. Would it be useful to use the build.zig dependency to make sokol-zig a dependency of sokol-d?

Not a fan tbh, it would probably make more sense to move the emsdk stuff into a separate project (and Zig package) which could then be used both by sokol-zig and sokol-d.

[floooh]

Wrote a ticket for that idea (to handle the C library stuff in sokol-zig build.zig): floooh/sokol-zig#71

[kassane]

it would probably make more sense to move the emsdk stuff into a separate project (and Zig package) which could then be used both by sokol-zig and sokol-d.

Make sense. Like,
https://github.com/kassane/anotherBuildStep (a.k.a abs)
Also, I have not yet completed emsdk support. But in pacman.d, besides sokol-d (passing libsokol + D modules), using abs to set ldc2.
Maybe ldc2/ldmd2 could be ported outside of sokol-d using this idea.