Adds LazyPath.dirname for getting the containing folder of a LazyPath

[ikskuh]

Use cases:

const config_h_step = b.addConfigHeader(
    .{
        .style = .{ .autoconf = .{ .path = "./flex-2.6.4/src/config.h.in" } },
    },
    flex_config,
);
const config_h = config_h_step.getOutput();

exe.defineCMacro("HAVE_CONFIG_H", null);
exe.addIncludePath(config_h.dirname());

const lexer_gen = b.addRunArtifact(flex);
lexer_gen.addArgs(&.{
    "--hex", //  use hexadecimal numbers instead of octal in debug outputs
    "--8bit", // generate 8-bit scanner
    "--batch", // generate batch scanner
    "--yylineno", //  track line count in yylineno
    "--prefix=apigen_parser_", // custom prefix instead of yy
    "--reentrant", // generate a reentrant C scanner
    "--nounistd", //  do not include <unistd.h>
    "--bison-locations", // include yylloc support.
    "--bison-bridge", // scanner for bison pure parser.
});
const lexer_c_source = lexer_gen.addPrefixedOutputFileArg("--outfile=", "lexer.yy.c");
const lexer_h_source = lexer_gen.addPrefixedOutputFileArg("--header-file=", "lexer.yy.h");
lexer_gen.addFileSourceArg(.{ .path = "src/parser/lexer.l" });

exe.addIncludePath(lexer_h_source.dirname());
exe.addCSourceFile(.{ .file = lexer_c_source, .flags = &lax_cflags ++ local_include });

[kubkon]

Nice! This will simplify my zld test harness a fair amount! With this change, I believe this becomes obsolete: https://github.com/kubkon/zld/blob/860135f3e4e1bae21688b09b110711dab799cb34/test/test.zig#L183-L206

[kubkon]

On WIndows, we will blindly return / as root for an abs path which is wrong.

[ikskuh]

On WIndows, we will blindly return / as root for an abs path which is wrong.

Actually not quite sure, windows also allows current-drive absolute paths that don't use a drive specifier (\Windows\system32\calc.exe) is valid if your CWD is in C:\. I gotta verify that, will test when i have a windows machine at hand

[kubkon]

Either way, whatever the actual drive or path notation is, we should return that instead of /.

[ikskuh]

After thinking about it for a while, i think the correct solution here is one of:

1. Panic and let the user fix it
2. Pass in a builder, resolve the paths to absolute paths and then invoke dirname on those (using . is also a bad idea here)
3. Rewrite the Build to allow using Build.relPath(…), Build.cwdPath(…) which both resolve to the correct path internally. This is probably the correct solution here, as .path is currently broken-by-design:
   What will happen if a dependency Build will pass a .{ .path = "local" } to a "higher" builder? It will suddenly point to a file in the local folder instead of the one where the dependency was fetched to.

cc @andrewrk

[kubkon]

Looks good, but a little bit more work is required to better support Windows :-)

[andrewrk]

I agree with supporting the use case (see #17411) however, I think this is not the best way to go about implementing it. I added a diff to that issue to show my counter-proposal for how to implement it.

One more thing that I want to do here is protect against this dirname function being used to go outside of a root dir. For example, it shouldn't be possible to go from a generated file inside the zig-cache to outside the zig-cache, or from a project-relative file to outside the project. It's less of a security concern issue, and more just that I want to prevent people from putting a bunch of brittle, janky logic in their build scripts.

[ikskuh]

Superseeded by #18371