programs and libraries used by the new derivation at run-time
whereas nativeBuildInputs contains
programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation
So does it matter? Worked with Nix expressions using both, and never experienced any issues, but I’m wondering if there is a “right way” or if there’s a situation where one of them could backfire?
In general though, nativeBuildInputs is useful for cross-compilation as commands from those derivations will be available on the buildPlatform and execute at build time. Whereas buildInputs will likely be the architecture of the hostPlatform, so the derivation can link against those inputs (and be used at run-time).
There’s some cases like python where you may need to list them both as a nativeBuildInputs and as a buildInput, if the package needs to run python during build and will link against it.
EDIT:
This has gotten a lot of views over the years, wanted to expand on this:
nativeBuildInputs: Should be used for commands which need to run at build time (e.g. cmake) or shell hooks (e.g. autoPatchelfHook). These packages will be of the buildPlatforms architecture, and added to PATH.
buildInputs: Should be used for things that need to be linked against (e.g. openssl). These will be of the hostPlaform’s architecture. With strictDeps = true; (or by extension cross-platform builds), these will not be added to PATH. However, linking related variables will capture these packages (e.g. NIX_LD_FLAGS, CMAKE_PREFIX_PATH, PKG_CONFIG_PATH)
In the early days of nix, packages were expected to be built by x86_64 and target x86_64. It wasn’t until later where cross compilation support was adopted. But to not break nix expressions outside of nixpkgs, the transition to enforcing the differences never happened. Individual packages can “opt-in” to using the more strict tooling divide by setting strictDeps = true; which will roughly emulate how PATH, NIX_CLFAGS_COMPILE, NIX_LD_FLAGS and other environment variables are constructed similar to a cross-platform build.
Outside of cross-compilation, adhering to good practices for nativeBuildInputs is still recommended because certain variables (e.g. XDG_DATA_DIRS) are safe to append to when of the same buildPlatform, but same is not true of hostPlatform packages. This can result in other quality-of-life additions such as bash completion being available for packages listed in nativeBuildInputs, but not for packages in buildInputs.
Additional Context:
Taking a package and pulling either the build or host platform variant is called splicing.
Packages specific to the buildPlatform can be found in buildPackages. This sometimes can be useful when using overrides, which may not respect splicing.
Similarly targetPackages have packages specific to the target platform (generally not useful for most packages except toolchains).
The default package set already targets hostPlatform, so you those are just referenced by pkgs in a general sense.
nativeBuildInputs and buildInputs are technically “legacy” terms, although still the standard convention in most nix packages. However, unless you’re writing packages which export toolchains (e.g. gcc, clang, interpreters), you likely wont need to use the more accurrate depsXXXYYY variants.
Thanks, and there’s a lot to unpack. What follows are mostly just notes so that it will make sense to me later.
Looking at the source of mkShell that you linked, it will call mkDerivation in the end.
As you stated that nix-shell treats both buildInputs and nativeBuildInputs the same (does this apply to other *Inputs as well?), I went ahead and poked around in NixOS/nix to find the source of nix-shell. Am I on the right track looking at nix-build.cc? My C knowledge is next to nothing, but the line below tells me that I’m probably am.
// nix-build.cc, line 89
auto myName = runEnv ? "nix-shell" : "nix-build";
Couldn’t figure out yet how and where *Inputs end up though.