build: regression: `file exists in multiple modules` with same module twice in dependency tree

[LordMZTE]

Zig Version

commit 9959319d5395a668867c90f63b5f82eb03f0ac9f up to current master (fd830b146dc733657aeb689e1321556395560bfd)

Steps to Reproduce and Observed Behavior

1. Construct a module tree where a module is depended on by 2 other modules. Here's a build.zig.zon with dependencies that produce this behavior:

.{
 .version = "0.0.0",
 .name = "my-project",

 .dependencies = .{
 .getty = .{
 .url = "https://github.com/getty-zig/getty/archive/4d58a31d9ea5728e7c0a3ca4158478468131fdd6.tar.gz",
 .hash = "1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870",
 },
 .getty_json = .{
 .url = "https://github.com/getty-zig/json/archive/b5f074d9adcff2ce5536436084465f08d52d1dff.tar.gz",
 .hash = "1220092d65c8a38c4fcd107fb016eb0c2339815dcca9733bdd0078a98a362e74a6b6",
 },
 },
}

Add both of these to a CompileStep:

exe.addModule("getty", b.dependency("getty", .{}).module("getty"));
exe.addModule("json", b.dependency("getty_json", .{}).module("json"));

2. Reference both modules in the exe's code:

_ = @import("getty");
_ = @import("json");

Alternatively this project of mine can reproduce this behavior (at the time of writing, the CI still passes due to it using a slightly outdated Zig build).

zig build-exe zupper Debug native: error: the following command failed with 1 compilation errors:
/home/lordmzte/dev/zig/build/stage3/bin/zig build-exe /home/lordmzte/dev/zupper/src/main.zig -larchive -lc -fno-strip --cache-dir /home/lordmzte/dev/zupper/zig-cache --global-cache-dir /home/lordmzte/.local/cache/zig --name zupper --mod ansi-term::/home/lordmzte/.local/cache/zig/p/1220647eea49d2c48d5e59354291e975f813be3cc5a9d9920a50bbfaa40a891a06ee/src/main.zig --mod zig-args::/home/lordmzte/.local/cache/zig/p/12203d04cafc97f952d74cdb077e74c0ab3414f9f6b5fbd159112c62bfa584a0dbed/args.zig --mod known-folders::/home/lordmzte/.local/cache/zig/p/122048992ca58a78318b6eba4f65c692564be5af3b30fbef50cd4abeda981b2e7fa5/known-folders.zig --mod getty0::/home/lordmzte/.local/cache/zig/p/1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870/src/getty.zig --mod getty::/home/lordmzte/.local/cache/zig/p/1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870/src/getty.zig --mod json:getty:/home/lordmzte/.local/cache/zig/p/1220092d65c8a38c4fcd107fb016eb0c2339815dcca9733bdd0078a98a362e74a6b6/src/json.zig --deps zig-args,known-folders,ansi-term,getty=getty0,json --listen=-
Build Summary: 0/3 steps succeeded; 1 failed (disable with --summary none)
install transitive failure
└─ install zupper transitive failure
 └─ zig build-exe zupper Debug native 1 errors
/home/lordmzte/.local/cache/zig/p/1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870/src/getty.zig:1:1: error: file exists in multiple modules
/home/lordmzte/.local/cache/zig/p/1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870/src/getty.zig:1:1: note: root of module root.json.getty
/home/lordmzte/.local/cache/zig/p/1220630b7523ccdfb21cb7f4f5f20f25a5cb52e1e74e2c62b513f88241b8b0c95870/src/getty.zig:1:1: note: root of module root.getty

A git bisect reveals that this is caused by commit 9959319d5395a668867c90f63b5f82eb03f0ac9f (#16600). Considering the aim of this PR, I guess it might be incorrectly assuming the dependencies are getting different options, even though getty always ends up with the same options (if we look at the build.zig in getty-json). This may be caused by 2 different instances of std.Build here.

Expected Behavior

The code compiles.

[mlugg]

...it might be incorrectly assuming the dependencies are getting different options, even though getty always ends up with the same options...

Unless I'm missing something, they absolutely don't have the same options? getty-json passes target and optimize to getty, whereas you don't. Try passing a target and optimize into both of your dependencies. It's a fairly common pattern to have to do this.

[LordMZTE]

Unless I'm missing something, they absolutely don't have the same options? getty-json passes target and optimize to getty, whereas you don't. Try passing a target and optimize into both of your dependencies. It's a fairly common pattern to have to do this.

It looks like this is the case, however my minimal example will still result in the same values being passed (the native target and debug optimization). Besides that, my project Zupper (linked above) which can reproduce this actually explicitly passes the same tuple to both dependencies.

[LordMZTE]

My CI can now reproduce this: https://wp.mzte.de/repos/110/pipeline/22/3

[mlugg]

Update: after some debugging here, it appears that getty-json is passing the target to getty as native-native, while the root build script is passing the target to getty as native, so the dependency is not deduped