I somewhat recently cleaned up the sokol-zig build.zig file and added a manual build step for installing the Emscripten SDK via zig build install-emsdk (previously this was done ‘on demand’ when doing the first build with target wasm32-emscripten).
Now of course I have the problem that this new build step isn’t available in downstream projects which use sokol-zig as dependency.
Is there a ‘clean’ way for a dependency to declare a build step as ‘public’ so that it is ‘inherited’ in downstream projects (or alternatively, ‘pull’ specific build steps from dependencies into the downstream build.zig)? The only way I can currently think of is to expose a public function installEmsdk from the sokol-zig build.zig which would return a *Build.Step, and import and call that function from the downstream project’s build.zig.
I’ve ran in to this problem quite a few times and always end up exposing a public function which dependents have to run which I don’t think is quite nice, both from a maintainers perspective and the users. I would however want to know why this is necessary for your emscripten dependency? Wouldn’t it be nicer to just document that the emsdk/emcc must be available on the system to build sokol? Then one can just point to where it lives on the system when importing the dependency as an option, and if it is null just check if it exists on path. This way you just send the problem downstream, and it lets users of sokol point it to whatever version of emsdk they want to use (and perhaps you can document a minimum/recommended version). Is there any particular reason you want sokol to own the installation of emsdk?
Not tested, but it should be possible to create a step, that depends on an element of dep.builder.top_level_steps. I’m not sure if this is considered an implementation detail, which shouldn’t be relied on. A similar thing is used here in the test-standalone step, of the compiler.
I don’t want to depend on a globally installed emsdk, mainly because of emsdk version requirements (e.g. I want to pin a specific version which is known to work, for instance because of regressions like this: JS exception/crash in emsdk 6.0.2 when calling UTF8ToString · Issue #27241 · emscripten-core/emscripten · GitHub). AFAIK global installation is also somewhat discouraged nowadays by the Emscripten team (they went to great lengths to make a ‘local’ emsdk installation work without having to setup any paths or environment variables).
