Build stage dependencies?

[tisonkun]

Currently, we can specify dependencies in build.zig.zon and add them in lib, exe or test deps by b.dependency.

However, if the build.zig itself wants to use a library, const libname = @import("libname") in build.zig seems import the build file of the dep. And as a result, I cannot use functions/types in that library.

What I need here may be compared to [build-dependencies] in Cargo.

[Vexu]

Should already be possible #14279

[xdBronch]

that imports the dependency's build.zig file, not a module of the dependency

[MGilleronFJ]

I think I'm going to have the same issue. I'd like to use ztracy to instrument some heavy code generation process which I want to be part of my build system, but ztracy are bindings to Tracy which is in C++ and has its own build.zig that needs to run for the thing to be functional.

I came across https://zig.news/liyu1981/how-to-use-your-fav-pkg-in-buildzig-3ni8 but that solution is not truly the same as using a regular dependency, since the behavior of @import is different, might require changes/forking the dependency to add extra declarations in their build.zig (which in my case would look quite horrible) and it seems it wouldn't really work in my case.

I'm already trying to support an optional build option where I build that generator as a standalone executable in order to make debugging sessions easier (I dunno how else to debug the build system). So for now I'm considering to workaround that by abandoning the idea of having functional profiling when building, with some sort of conditional compilation:

const ztracy = if (is_in_build_system) @import("my_own_dummy_wrappers_that_do_nothing.zig") else @import("ztracy")

But I also don't know what to put in is_in_build_system, so I end up falling back to manually commenting things in and out, which is quite ugly in version control.

Having some kind of proper build-system dependencies would make all this much easier (not just for my specific case, which has some workaround options, but any other cases where a lib is needed (and not necessarily pure zig) without having to overcome different behavior of @import).

[mocompute]

Two comments:

• You have access to any public export from the imported build.zig, which might be enough. However, if the imported build.zig file itself imports a module from a dependency, this approach will fail.
• Because of that, I took the approach of making a two stage build, where the first stage invokes a tool in the imported module, and that tool generates a new zig source file. That generated file is imported by the main build.zig and exports build steps or whatever.

As far as I know, this is the only way to have a build-time dependency on logic provided by a complex dependency (which itself uses the zig package manager for further dependencies). This is an understandable limitation at this stage of Zig but I do hope it can be addressed at some point.

[the-nurk]

also looking to do this. it's crazy, but we go hard on earth.