It looks like @import("build") no longer works, could somebody tell me the current correct way to access build options in application code ?
This is a very hard thing to Google so apologies if this is covered elsewhere.
#How to access build options ?
wheat imp
pure yarrow
@import("builtin")
to see what you get from this import you can execute zig build-exe --show-builtin
wheat imp
@pure yarrow I may be doing something wrong, but if I do this:
const httpz_dep = b.dependency("httpz", .{ .target = target, .optimize = optimize, .httpz_blocking = true });
and then run zig build-exe --show-builtin I don't see the httpz_blocking build option.
vapid oracle
you need to use a combination of b.option and b.addOptions
you will specify the name of the options module, and use that to import
wheat imp
@vapid oracle Here's the relevant code for that:
options.addOption(bool, "httpz_blocking", false);
httpz_module.addOptions("build", options);
Note that this isn't my code, just trying to fix it for a PR.
opaque ocean
the build options on httpz won't be accessible from your code unless the library re-exports it, but you can add your own options like that
wheat imp
I'm now realising that @import("build") was a custom name, not a builtin.
vapid oracle
yes, it’s specified in the addOptions
wheat imp
So @import("build") should work in this case, no ?
wheat imp
/home/bob/dev/zig/jetzig/demo/../../http.zig/src/httpz.zig:32:23: error: no module named 'build' available within module root.@dependencies.1220d464f7a8d2c01e86a5519e6fb3cac31fe1812fcd3f6c9a1f02fe69a918139128
const build = @import("build");
I think this might be because I'm referencing the module at build time by importing it in the library's build.zig.
pub const httpz = @import("src/httpz.zig");
that would do it
wheat imp
That's unfortunate, I've used this approach elsewhere when I need to use a dependency at both build time and run time, so I'm not sure how to work around it in this case.
vapid oracle
could you give a bit more detail on what you’re reusing and how
wheat imp
In build.zig I do this:
pub const httpz = @import("src/httpz.zig");
Then in src/http.zig I do this:
pub const httpz = @This();
And then I import it in my application like this:
pub const httpz = @import("httpz").httpz;
This allows the module to be used by things that execute at build time and also at run time. It's the only way I've found to solve this issue, so maybe there is a better way ? Not sure what other details to provide but happy to give them if you can be more specific.
ebon pendant
You can't import a module from within the context of the build system in the way you are trying to do.
You can think of build.zig as its own separate program, which is compiled independently. It can import the same source files as your main executable, but it is completely unaware of the main exe's compile options or which modules it imports. This means that if src/httpz.zig imports a different module (in this case build), your build.zig will be unable to use it because there's no way to make the build module available to the build system itself.
In other words, imports in build.zig are limited to std, builtin and "dumb" source files that don't depend on any other modules.
What are you trying to do? Why do you need to use http.zig from build.zig?
wheat imp
@ebon pendant Makes sense to me.
At build time my application (a web framework) does a lot of stuff at build time like generating routes, pre-rendering static responses, etc. It does this mostly through secondary executables that are compiled at build time and then run before launching a web app. I'm just trying to find a more concise answer to your question (it's been a while since I looked at this part), but essentially parts of httpz are referenced by other modules that are used at build time (e.g. the Request module).
I'm going to see if I can avoid loading httpz at build time.
ebon pendant
Maybe you could split up the files so that the ones you need at build time don't reference any external dependencies.
wheat imp
An alternative here would be to wrap the import in some kind of conditional, so e.g.:
const httpz_nonblocking = if (is_build) @import("build").httpz_nonblocking else false;
But I'm not sure what I would use in place of is_build.
Yeah I think that's a good idea - it would be an improvement on factoring as a bonus.
I got my ternary the wrong way round but you get the idea.
ebon pendant
An alternative here would be to wrap the import in some kind of conditional, so ...
This would be an enormous hack but const is_build = @hasDecl(@import("root"), "root") and @hasDecl(@import("root"), "dependencies") might work
For context, in the build system, root points to the build runner, which is https://github.com/ziglang/zig/blob/master/lib/compiler/build_runner.zig by default