Skip to content

More consistent way to add build options modules #14979

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hryx opened this issue Mar 17, 2023 · 1 comment
Closed

More consistent way to add build options modules #14979

hryx opened this issue Mar 17, 2023 · 1 comment
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@hryx
Copy link
Contributor

hryx commented Mar 17, 2023

In the build system, OptionsSteps are a nice way to pass build variables to Zig code being built. But there is a small incongruity between how you do it for CompileSteps and for Modules.

pub fn build(b: *std.Build) void {
    // Get option values from the CLI and create options module
    const sideways = b.option(bool, "sideways", "you know what this means") orelse false;
    const shared_opts = b.addOptions();
    shared_opts.addOption("sideways", sideways);

    // For CompileStep, use addOptions()
    const exe = b.addExecutable("pigeon", .{});
    exe.addOptions(shared_opts); // <--

    // For Module, pass as a dependency
    const mod = b.addModule("chicken", .{
        .root_source_file = .{},
        .dependencies = &.{ shared_opts.createModule() }, // <--
    });
}

I think there could be a less confusing API. Possibilities:

  1. Duplicate the addOptions method to Module.
  2. Remove addOptions so that CompileStep and friends instead use exe.addModule("options", my_opts.createModule()), closing the discrepancy.
  3. Something else?
@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Mar 17, 2023
@andrewrk andrewrk added this to the 0.11.0 milestone Mar 17, 2023
@andrewrk andrewrk added breaking Implementing this issue could cause existing code to no longer compile or have different behavior. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. labels Mar 17, 2023
AdamGoertz added a commit to AdamGoertz/zig that referenced this issue Apr 1, 2023
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Jul 22, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Aug 5, 2023
@xdBronch
Copy link
Contributor

xdBronch commented Jan 7, 2024

i believe this can be closed after the modules rework, build options are done by adding it to a compile steps root_module now

@Vexu Vexu closed this as completed Jan 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase. zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
None yet
Development

No branches or pull requests

4 participants