Zig build system will silently link objects compiled with conflicting flags and makes it easy to do this accidentally

[the-argus]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

clone my repository https://github.com/the-argus/squinchwerms and checkout commit d8e69dbae6953b88c1be32c66d878e04f7c5b4ee which should be on the okaylib branch.
run zig build -Dcpu=baseline and debug the output program with GDB, and input the following commands:

> b space.h:15
> r
> p sizeof(cpSpace)
> s
> p sizeof(cpSpace)

The p sizeof(cpSpace) should output 440 the first time but 568 the second time, because you will have stepped into a source file compiled with the chipmunk2d builder which has -DCP_USE_DOUBLES=1. My project has -DCP_USE_DOUBLES=0, which makes it think the struct is smaller. Switching the flag off for the library (by passing in .use_doubles = false to the build options) fixes the issue. Removing the flag in my project after that will break things, though, because the flag is not propagated up from the dependency.

Expected Behavior

Primarily, I expect linking libraries to have some concept of "public" and "private" flags so that some will be propagated upstream to ensure ABI compatibility. Optionally, it would be nice if there was some warning or separate API for overriding / conflicting with flags from linked objects.

Additionally, this lack of propagating flags and dependencies means that header-only libraries cannot be propagated to depending packages. For example, I have a library that uses fmtlib, and the repo I posted above uses that library, but I have to add fmt to my build.zig.zon and duplicate the following into my build script:

    const fmt = b.dependency("fmt", .{});
    const fmt_include_path = b.pathJoin(&.{ fmt.builder.install_path, "include" });
    try flags.append(b.fmt("-I{s}", .{fmt_include_path}));
    exe.step.dependOn(fmt.builder.getInstallStep());

I think it may be caused by the same thing (no of propagation of CLI flags). But it's possible that the fmt installStep dependency is also not propagated, in which case this may be out of the scope of this ticket and I'll make a separate issue. Also, maybe I am just doing this wrong :P