LibExeObjStep.addBuildOption doesn't import the type

[SamTebbs33]

addBuiltOption doesn't import the type passed.

build.zig

const Builder = @import("std").build.Builder;
const builtin = @import("builtin");
const Arch = builtin.Arch;

pub fn build(b: *Builder) void {
    const exe = b.addExecutable("foo", "foo.zig");
    exe.addBuildOption(Arch, "arch", builtin.arch);
    exe.install();
    b.default_step.dependOn(&exe.step);
}

foo.zig

const options = @import("zig-cache/foo_build_options.zig");
const warn = @import("std").debug.warn;

pub fn main() void {
    warn(@tagName(options.arch));
}

/home/sam/repos/zig/build/zig build-exe /home/sam/foo.zig --pkg-begin build_options /home/sam/zig-cache/foo_build_options.zig --pkg-end --cache-dir /home/sam/zig-cache --name foo --cache on
/home/sam/zig-cache/foo_build_options.zig:1:18: error: use of undeclared identifier 'Arch'
pub const arch = Arch{ .x86_64 = void };

If the type is not one of the built-in types (uX, bool etc.) then an import should be added.

[courajs]

I've just added build option support for arrays/slices of primitives in #10016

But I've been trying to figure out whether there's a good way to support structs/unions in the general case.

1. How can we know whether a type is from the standard library or not? I can only think either of a prefix check on @typeName, or some sort of reflection crawl of the std package, which I believe would cause everything to be semantically analyzed.
2. What about arbitrary user-defined types? We could add a declaration for them, but what about anonymous types? Should we require a name for them?
3. What about imports from other, non-std packages? Is/could this even be allowed in build.zig? If so, can we guarantee that the main project will see a value of the actual type from the aux package? (rather than some structurally identical but separate type)
4. What about generics? How would we know the proper function to import, and what arguments to pass? Again, the only thing I can think of here is a string check of @typeName (ew), or using reflection to generate a declaration which seems it would break our type equality semantics.

[leecannon]

Due to the way build options currently functions (a seperate package) it cant really handle user types defined within the program itself without the build option package having dependencies on all the packages the LibExeStep depends on.

If it did, having addBuildOption work for known types like Arch, Version, etc but requiring a seperate addBuildOptionExtended which takes a fully qualifed type would allow:

const Builder = @import("std").build.Builder;

const MyStruct = @import("src/lib.zig").MyStruct;

pub fn build(b: *Builder) void {
    const exe = b.addExecutable("foo", "foo.zig");
    exe.addBuildOptionExtended(MyStruct, "option", .{}, "@import(\"root\").MyStruct");
    exe.install();
    b.default_step.dependOn(&exe.step);
}

which would result something like: pub const option: @import("root").MyStruct = .{}; although it should probably result in fully initalizing all fields to be the same as the instance passed to addBuildOptionExtended

[courajs]

Would that run into problems as src/lib.zig is now being compiled twice, with potentially different build configuration? For example when cross-compiling, I assume build.zig is compiled natively, then the build.zig configures the main build to compile for a different target. The types might be different based on that.
Similarly, it wouldn’t have access to any of the other build options - but there’s probably no reasonable way around that