Need a way to disambiguate dependency artifacts with the same name

[alexrp]

(There was some earlier discussion on this on the Zig Discord.)

Right now, if a dependency project has multiple artifacts with the same name, you're going to hit this panic:

zig/lib/std/Build.zig

Lines 1855 to 1871 in 451550e

	pub fn artifact(d: *Dependency, name: []const u8) *Step.Compile {
	var found: ?*Step.Compile = null;
	for (d.builder.install_tls.step.dependencies.items) |dep_step| {
	const inst = dep_step.cast(Step.InstallArtifact) orelse continue;
	if (mem.eql(u8, inst.artifact.name, name)) {
	if (found != null) panic("artifact name '{s}' is ambiguous", .{name});
	found = inst.artifact;
	}
	}
	return found orelse {
	for (d.builder.install_tls.step.dependencies.items) |dep_step| {
	const inst = dep_step.cast(Step.InstallArtifact) orelse continue;
	log.info("available artifact: '{s}'", .{inst.artifact.name});
	}
	panic("unable to find artifact '{s}'", .{name});
	};
	}

There are legitimate reasons to have artifacts with the same name. For example, in my case, I'm building both a static and shared library. They have the same name because I want them to end up as libfoo.so and libfoo.a. I think the build system needs some way for dep.artifact("foo") to work in this scenario.

[rohlem]

They have the same name because I want them to end up as libfoo.so and libfoo.a.

std.Build.Dependency.artifact returns a *std.Build.Step.Compile, which has a field out_filename (and out_lib_filename).
I think you should be able to refer to them as "fooDynamic" and "fooStatic", and then tweak these field values so they are still generated with the name you want.
I hope that helps, not sure if this fully addresses your use case though.

[alexrp]

Only partially. Those fields aren't used in all the places you'd hope/expect compared to name. There's also the issue that they include all the target-specific prefixes/suffixes, so you lose quite a bit of abstraction once you start mucking with them.

Another separate but related issue is that if the static library in my scenario has a different name on Windows (to avoid conflicting with the shared library's generated import library), the user of my library has to replicate the logic to pick the artifact name based on whether the target is Windows. Having a separate "artifact name" concept that is distinct from "application/library name" would solve that, too.

[BratishkaErik]

Related: #18513 .

I suggested in Discord to separate creating a module/artifact and exporting it for the package manager in two different calls, which should fix this problem and make a nice simmetry with dep.module("...") and dep.artifact("...") calls in downstream consumers:

const mod = b.createModule(.{
    .root_source_file = b.path("src/main.zig"),
    .target = target,
    .optimize = optimize,
});
mod.expose("main");
// In downstream: b.dependency(...).nodule("main")

const exe = b.addExecutable(.{ .name = "project", ... });
const lib = b.addExecutable(.{ name = "project", ... });
exe.expose("main-exe");
lib.expose("main-lib");
// In downstream: b.dependency(...).artifact(...);

Since this is a rare case, we can make Step.Compile.expose to accept struct instead, with default field = null meaning "take name from the artifact itself", so that for common cases user do not need to repeat name of artifact twice.

[Lzard]

Would adding an output_name optional field to addStaticLibrary/addSharedLibrary options and use it to construct the related Step.Compile fields be a good solution to this?

[alexrp]

Would adding an output_name optional field to addStaticLibrary/addSharedLibrary options and use it to construct the related Step.Compile fields be a good solution to this?

That was more or less my initial suggestion in the Discord discussion. Having slept on it, though, I'm starting to warm to the idea of having an explicit gesture to "export" an artifact from the build script, just like how marking an artifact for installation is an explicit gesture. It feels more "Zig-y".