-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
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):
When |
I implemented the ability to add recursive packages to Also in that PR was an implementation for a proposal to add a 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. // 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 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. |
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.
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
build.zig
build.zig of android-sdk:
cc @MasterQ32
The text was updated successfully, but these errors were encountered: