provide buildpkgs module to build.zig

[marler8997]

Alternative to #8033 (add @tryImport)

implement the main part of #8070 (Dynamic build.zig dependencies)

See the linked proposal for more details. To summarize what this PR includes. zig build has been modified to generate a corresponding buildpkgs.zig module for any build.zig that it compiles (also one for all its sub-packages). This buildpkgs.zig module contains a list of all the packages that are available to build.zig. This allows build.zig to know at comptime whether a package is available, before it attempts to import it. The linked issue above explains why this is necessary for build.zig.

[daurnimator]

Comments on implementation. I still need to think about the design.

[daurnimator]

the below inline for uses names rather than name

[marler8997]

it's supposed to be names, names is declared above

[daurnimator]

why? The parameter is already comptime known, why must the mem.eql happen at comptime?

[marler8997]

See the doc comment in test/standalone/buildpkgs/missing-comptime/build.zig.

//! Currently the user MUST specify comptime when calling "buildpkgs.has"
//! until #425 is implemented.
//! This build.zig file tries to call "buildpkgs.has" without comptime and the
//! test is to make sure it produces a compile error.
//!
//! Note that the reason why "buildpkgs.has" must be evaluated at comptime is
//! because it will always surround an @import statement. The problem is
//! that if they forget to add "comptime" to their call, then their build.zig
//! file will "sometimes work" so long as they are building with the necessary
//! packages configured, but then it will fail once the @import is missing
//! which defeats the whole purpose of providing "buildpkgs.has" in the first place.
//!

This is one disadvantage this solution currently has over @tryImport. If the user forgets to add comptime, then Zig evaluates it at runtime becuase buildpkgs.has returns a bool type. This is being addressed with #425 which allows you to force comptime with callconv(.Inline). With @tryImport it returns ?type so it has to be evaluated at comptime so there's no issue. The real problem though is that missing comptime won't always result in a compile error, if you're only testing cases where the package is supplied then it will just work and you'll miss the bug. This code makes sure that you always get a compile error when you forget comptime instead of leaving a bug in your code.

Note that the other solution I thought of was to create a tryImport wrapper around the has function in buildpkgs.zig:

pub fn tryImport(comptime name: []const u8) ?type {
    return if (comptime has(name)) @import(name) else null;
}

However, because of this accepted proposal: #2206, all @import calls will require string literals, so this won't work once that is implemented. I'm am a bit dissapointed that we won't be able to expose a tryImport because it means the user must specify the same package name twice, which provides more opportunity for errors (espcially copy/paste one):

if (comptime @import("buildpkgs").has("foo")) {
    const foo = @import("foo");
}

// VS

if (@import("buildpkgs").tryImport("foo")) |foo| {
}

As you can see, tryImport has 2 advantages, the first is you don't have to maintain 2 copies of the same package name in your code, and the second is you're no longer required to specify comptime when you call it because it returns a comptime value, ?type.

[Vexu]

I'll close this pr for now since we want to reserve the pull request queue for prs that are ready to be merged. I'll add a reminder to the issue about this implementation.