Extracted from #14265.
I can think of two possibilities:
This is straightforward to implement; it would run this code, without actually running the build_runner:
| if (!build_options.omit_pkg_fetching_code) { |
| varhttp_client: std.http.Client= .{ .allocator=gpa }; |
| deferhttp_client.deinit(); |
| tryhttp_client.rescanRootCertificates(); |
| |
| // Here we provide an import to the build runner that allows using reflection to find |
| // all of the dependencies. Without this, there would be no way to use `@import` to |
| // access dependencies by name, since `@import` requires string literals. |
| vardependencies_source=std.ArrayList(u8).init(gpa); |
| deferdependencies_source.deinit(); |
| trydependencies_source.appendSlice("pub const imports = struct {\n"); |
| |
| // This will go into the same package. It contains the file system paths |
| // to all the build.zig files. |
| varbuild_roots_source=std.ArrayList(u8).init(gpa); |
| deferbuild_roots_source.deinit(); |
| |
| // Here we borrow main package's table and will replace it with a fresh |
| // one after this process completes. |
| main_pkg.fetchAndAddDependencies( |
| &thread_pool, |
| &http_client, |
| build_directory, |
| global_cache_directory, |
| local_cache_directory, |
| &dependencies_source, |
| &build_roots_source, |
| "", |
| ) catch|err|switch (err) { |
| error.PackageFetchFailed=>process.exit(1), |
| else=>|e|returne, |
| }; |
| |
| trydependencies_source.appendSlice("};\npub const build_root = struct {\n"); |
| trydependencies_source.appendSlice(build_roots_source.items); |
| trydependencies_source.appendSlice("};\n"); |
| |
| constdeps_pkg=tryPackage.createFilePkg( |
| gpa, |
| local_cache_directory, |
| "dependencies.zig", |
| dependencies_source.items, |
| ); |
| |
| mem.swap(Package.Table, &main_pkg.table, &deps_pkg.table); |
| trymain_pkg.addAndAdopt(gpa, "@dependencies", deps_pkg); |
| } |
One thing to consider would be a slightly higher level abstraction of subcommand which would additionally build and install dev dependencies. For example, if there were a binary tool that should be available, it should get installed. But that can be a follow-up issue.
I think I like the zig build --fetch option better because zig fetch sounds like it might download a URL directly, which is not an outrageous idea considering the "Zig as Dependency Zero" motto.
Extracted from #14265.
I can think of two possibilities:
This is straightforward to implement; it would run this code, without actually running the build_runner:
zig/src/main.zig
Lines 4080 to 4126 in 7cb2f92
One thing to consider would be a slightly higher level abstraction of subcommand which would additionally build and install dev dependencies. For example, if there were a binary tool that should be available, it should get installed. But that can be a follow-up issue.
I think I like the
zig build --fetchoption better becausezig fetchsounds like it might download a URL directly, which is not an outrageous idea considering the "Zig as Dependency Zero" motto.