Skip to content
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

ability to @import dependencies directly in build.zig scripts #14279

Closed
Tracked by #14265
andrewrk opened this issue Jan 12, 2023 · 2 comments · Fixed by #14859
Closed
Tracked by #14265

ability to @import dependencies directly in build.zig scripts #14279

andrewrk opened this issue Jan 12, 2023 · 2 comments · Fixed by #14859
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Jan 12, 2023

Extracted from #14265.

Within a build.zig file, @import should be allowed, and it should refer to the build.zig file of any dependencies listed in the manifest file.

Example:

build.zig.zon

    .dependencies = .{
        .@"android-sdk" = .{
            .url = "...",
            .hash = "...",
        },
    },

build.zig

const std = @import("std");

pub fn build(b: *std.build.Builder) void {
    const exe = b.addExecutable("app", "src/main.zig");

    @import("android-sdk").helperFunction(exe);
}

build.zig of android-sdk:

const std = @import("std");

pub fn build(b: *std.build.Builder) void {
    // ...
}

pub fn helperFunction(artifact: *std.build.LibExeObjStep) void {
    // ...
}

cc @MasterQ32

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Jan 12, 2023
@andrewrk andrewrk added this to the 0.11.0 milestone Jan 12, 2023
@andrewrk andrewrk mentioned this issue Jan 13, 2023
32 tasks
@ikskuh
Copy link
Contributor

ikskuh commented Jan 13, 2023

Yep that should be fully sufficient, as long as transitive dependencies work and will be properly deduplicated. So the following thing should work (assuming matching versions):

root_project
  -> library_a
  -> library_b
    -> library_c
      -> library_a

When library_b returns a type from library_a, those should be the same as the ones returned from the root_project dependency library_a.

@marler8997
Copy link
Contributor

I implemented the ability to add recursive packages to build.zig in this PR: #8072

Also in that PR was an implementation for a proposal to add a buildpkgs builtin that build.zig could use to query optional dependencies.

That PR allowed you to do something like this:

const buildpkgs = @import("buildpkgs");
if (comptime buildpkgs.has("android-sdk")) {
    const android_sdk = @import("android-sdk");
    // code that handles having android-sdk
} else {
    // code that handles NOT having android-sdk
}

Looking back now it feels like there might be a slightly better interface. buildpkgs.zig could maybe look something more like this:

// if android sdk is available
pub const android_sdk: ?type = @import("android-sdk");
// if android sdk is not available
pub const android_sdk: ?type = null;

Then in build.zig

const buildpkgs = @import("buildpkgs");
if (buildpkgs.android_sdk) |android_sdk| {
    // code that handles having android-sdk
} else {
    // code that handles NOT having android-sdk
}

Not familiar with the new package manager constructs yet so the same concept might look different.

lucas-yotsui added a commit to lucas-yotsui/UniMicro that referenced this issue Jul 30, 2024
Alright, I'll just say it so that nobody else does: this is not my
finest work.

However, I've been playing with this for a while now and I'm honestly
kind of tired for now. I'll leave it be for a while and maybe someday I
get back to it.

Major issues I have with it for now:
>  1 - Build system does not make a regular module for import. Instead
it relies on the build system importing. I honestly can't explain it
properly, but check the source code and [this
issue](ziglang/zig#14279). I feel like this is
kind of janky, since my LSP doesn't even detect the import in code, so I
don't get any sort of autocomplete.
>
>  2 - Certain optimize modes throw away important pieces of code, which
is unacceptable. It should optimize all the regular code parts while
keeping the essentials, such as gpio writes and etc.
>
>  3 - Still haven't worked very much on the interrupt overriding
interface. The linker provides the symbols, but the code doesn't really
do anything with it. I want to restructure this module to make these
handlers properly overridable and take advantage of the interrupts array
in the *'supported_chips'* structure.
>
>  4 - The GPIO functions do not work, but using the registers directly
does. In theory they are exactly the same thing, but something is off.

Honestly, the biggest issue for me right now is the lack of LSP support.
The rest is likely easy to fix, but not having an LSP really delays my
coding.

I don't know how or when I'll fix all of these issues or if it's even
possible, but that's for a future moment.
@mlugg mlugg moved this to Urgent Enhancements in Package Manager Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
Archived in project
3 participants