std.Build.LazyPath: upgrade API usages of source-relative path

[andrewrk]

The first commit deletes the deprecated API and then makes all the upgrades needed to pass the standalone tests.

The second commit reverts the API breakage. The second commit can be reverted once 0.12.0 is tagged.

@castholm re:

'path' lazy paths are relative to the build root of some step, inferred from the step
in which they are used. This means that we can't dupe such paths, because they may
come from dependencies with their own build roots and duping the paths as is might
cause the build script to search for the file relative to the wrong root.
As a temporary workaround, we convert build root-relative paths to absolute paths.
If/when the build-root relative paths are updated to encode which build root they are
relative to, this workaround should be removed.

The *Build argument to LazyPath.dupe was only being used for its allocator, and all instances share the same allocator. So converting a path prematurely to an absolute path was unnecessary and introduced unwanted absolute paths.

- /// Duplicates the file source for a given builder.+ /// Copies the internal strings.+ ///+ /// The `b` parameter is only used for its allocator. All *Build instances+ /// share the same allocator.
pub fn dupe(self: LazyPath, b: *Build) LazyPath {

[castholm]

@andrewrk

So converting a path prematurely to an absolute path was unnecessary and introduced unwanted absolute paths.

It wasn't unnecessary and was required specifically for installLibraryHeaders when the library came from a dependency. Prior to eee5400, the following repro failed:

// foo/build.zigconststd=@import("std");
pubfnbuild(b: *std.Build) void {
constlibfoo=b.addStaticLibrary(.{
.name="foo",
.target=b.resolveTargetQuery(.{}),
.optimize=.Debug,
});
libfoo.addCSourceFile(.{ .file=b.addWriteFiles().add("empty.c", "") });
libfoo.installHeader(.{ .path="header.h" }, "foo/foo.h"); // <------------ Note: .path, not .src_pathb.installArtifact(libfoo);
}

// foo/header.h
#defineFOO_FOO"FOO"

// build.zigconststd=@import("std");
pubfnbuild(b: *std.Build) void {
constexe=b.addExecutable(.{
.name="main",
.target=b.resolveTargetQuery(.{}),
.link_libc=true,
});
exe.addCSourceFile(.{ .file=b.addWriteFiles().add("main.c",
\\#include <stdio.h>\\#include <foo/foo.h>\\int main(void) {\\ printf(FOO_FOO "\n");\\ return 0;\\}
) });
constfoo_dep=b.dependency("foo", .{});
constlibfoo=foo_dep.artifact("foo");
exe.linkLibrary(libfoo);
exe.installLibraryHeaders(libfoo);
b.getInstallStep().dependOn(&b.addInstallArtifact(exe, .{
.h_dir= .{ .override=.header }, // <---------------- This is the thing that fails
}).step);
construn_exe=b.addRunArtifact(exe);
run_exe.step.dependOn(b.getInstallStep());
construn=b.step("run", "Run the app");
run.dependOn(&run_exe.step);
}

// build.zig.zon
.{
.name="main",
.version="0.0.0",
.dependencies= .{
.foo= .{
.path="foo",
},
},
.paths= .{""},
}

zig build run

error: unable to update file from 'C:\temp\header.h' to 'C:\temp\zig-out\include\foo\foo.h': FileNotFound

Note that 0b7123f made installing headers to the .header install dir the default for .lib artifacts, so until the deprecated .path is fully removed, they will run into this problem if they use installLibraryHeaders with lazy paths specified with .path.

It's probably not worth keeping the workaround; the fix is just to use the new b.path(...), but for a few days the workaround was justified 🙂

[Inve1951]

to*

[andrewrk]

Understood, thank you for the clarification!