a zig build mode intended to be used when packaging an application or library for a system distribution

[andrewrk]

This proposal is accepted; please see these comments for the criteria for closing the issue:

• a zig build mode intended to be used when packaging an application or library for a system distribution #14281 (comment)
• a zig build mode intended to be used when packaging an application or library for a system distribution #14281 (comment)

---

Extracted from #14265.

The use case is as follows:

Someone wants to take an upstream application, and package it for a Linux distribution, or another kind of distribution such as Homebrew or Nix.

The application knows exactly what versions of each dependency it wants to build against, but distributions only provide a limited set of versions. Furthermore, the system distribution wants to be in charge of providing all dependencies, building the application from source without access to any files outside of those provided by the system itself, via its own dependency management system.

For this use case, instead of fetching dependencies from the URLs provided by zig build.zig.zon files, instead there should be some kind of override that makes the dependencies fetched from the system package manager.

Related: Stay Together For The Kids: Why System Package Managers and Language Package Managers Struggle to Cooperate

[daurnimator]

For this use case, instead of fetching dependencies from the URLs provided by zig build.zig.toml files, instead there should be some kind of override that makes the dependencies fetched from the system package manager. Perhaps Zig can provide tooling that makes an application support being built in both contexts.

As long as zig can be pointed at a local directory for each dependency instead of ever fetching itself, then the external packaging systems (and/or the tooling around it) can be made to work.

[andrewrk]

I suspect that, in this mode, it will be necessary for zig to shell out to the system C/C++ compiler toolchain instead of relying on its own embedded clang library code. This is a very large can of worms, but, if we accept the foundational premise that zig build is intended to be truly used as a competitor to other build systems, this point is non-negotiable.

[motiejus]

Edit: moved to #14283 (comment)

[nektro]

i think something akin to CMAKE_PREFIX_PATH could help a lot here. in a system package manager environment, it could be populated by them, and if its empty zig could fill the value itself

https://cmake.org/cmake/help/latest/envvar/CMAKE_PREFIX_PATH.html

[andrewrk]

The equivalent parameter in zig build is --search-prefix

[nektro]

yes but i mean a variable different but similar for finding zig packages instead of cmake packages

[andrewrk]

Note what's happening over at NixOS/nixpkgs#241741.

They are creating common logic for packaging Zig applications on NixOS and have this line:

zig build -Drelease-safe -Dcpu=baseline $zigBuildFlags

This is a bit of a problem because -Drelease-safe, while commonly exposed,

• Is not always exposed because the build script might build multiple things and a single choice like this might not make sense
• The upstream author might expose only -Drelease because they want to choose the safety/size tradeoff.

Furthermore, -Dcpu is also not necessarily exposed, for similar reasons. There might be different things being built, with different CPUs. Anything could happen.

What we need is a way for nix and other systems to be able to specify their true intent, which is this:

• Make a release build, not a debug build.
• Any binary artifacts that otherwise would be compiled for the native host, compile them for this target/cpu instead.

We should make both of these things easy to specify, regardless of what is in the upstream application's build.zig script.

Here is my concrete proposal:

• Add a --release flag to zig build. So they can change -Drelease-safe to --release. In build.zig, upstream authors can observe this boolean, and pick a release mode, or, if they don't pick, an error will be emitted, something like, "upstream package supports fast, safe, and small. Please choose: --prefer-fast, --prefer-safe, or --prefer-small." Those options are also options that zig build will unconditionally support. So, probably Nix will have this: zig build --release --prefer-safe.
• Add --override-host-target <target> and --override-host-cpu <cpu> flags to zig build. These are always supported, and do what they say on the tin: any time the host target or cpu would be used, the provided one is used instead.

Finally, we need to also tackle one more problem, which is that zig packages need to know when they are being built in a mode that means they should try to depend on system libraries rather than fetching dependencies via the zig build system. For this I think we will need one or more flags, but I haven't quite thought through all the ramifications and how exactly this will be integrated into systems like Debian or Nix, but that concern should not block the implementation of these other flags, which would help Nix right now.