I don't think exposing the whole library inside the build.zig is a good idea.

Back then when I wrote that code, the build system dependency system was not as evolved as it is now. It now have LazyPath for easier dependency on generated files. You should make the image conversion tools actual tools created using the host build target and add the image tool invocation as a dependency to the GBA ROM you are building. Then you'll able to pass zigimg a module to the image conversion tool. It will require work but it will lead to better code in the end.

Here how I gather the build host target in my personal game engine to build the cook tool. You can use the optimize flag you pass to the zig build or force to build it in ReleaseSafe or ReleaseFast to always have the image conversion tool be fast if you want.

const build_host_target = b.resolveTargetQuery(.{
        .os_tag = builtin.os.tag,
        .abi = builtin.abi,
    });

What is the benefit of doing it that way? I had leaned toward doing the asset processing within build.zig as it seems to have a lot of significant benefits: The interface to asset processing tools is checked through Zig's type system rather than serializing everything as strings to be passed on the command line, they can also return metadata or error information that is type checked and that does not have to be serialized and deserialized, and those tools can be more easily combined into multi-step processes without intermediate writes to disk.

Hi! I would like to add my 2¢ as I also depend on zigimg for exactly the same reason (tooling / assets). Been looking the issues and pull requests to see how the migration to 0.15 is going and this PR drew my attention.

FWIW build.zig is only for constructing the build graph (there's even an issue to sandbox it ziglang/zig#14286 and other to separate it from the build runner).

Also AFAIK build.zig is compiled always in Debug mode (correct me if I'm wrong), thus it'll be a lot faster to do all the image encoding / decoding in a separate binary.