extraBuildInputs / extraNativeBuildInputs?

Development Documentation
1

I’d like to know if we still should use buildInputs and nativeBuildInputs, as they are marked as legacy names. There is extraBuildInputs and extraNativeBuildInputs, but I can’t find those in setup.sh, so I’m not quite sure.

Also, what is the difference between native and non-native within the build script?

1 Like
2

I’d like to know if we still should use buildInputs and nativeBuildInputs

Yes you should. The reasoning behind labeling them ‘legacy’ is because mkDerivation was overhauled to support the full host/build/target relation some time in the past.

In the new model depsBuildHost or depsBuildHost would be more accurate descriptions of these variables, but as the manual details the old names are retained for historical continuity.

I guess legacy implies there’s something newer you should use instead, but that’s not the case. It’s just about the naming scheme. That’s somewhat unfortunate…

Also, what is the difference between native and non-native within the build script?

This distinction is of importance when cross compiling. I scrapped my own explanation of these terms, and will just cite the relevant bits of the manual instead:

nativeBuildInputs

These are 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.

buildInputs

These are often programs and libraries used by the new derivation at run-time, but that isn’t always the case. For example, the machine code in a statically-linked library is only used at run-time, but the derivation containing the library is only needed at build-time.

My mental heuristic that gets it right most of the time (I guess) is: if it’s run or otherwise used at build time it’s a nativeBuildInput, otherwise buildInput.

Even if you’re not cross compiling yourself, try to get them right - someone might try to cross compile your derivation one day.

All of this is answered in the nixpkgs manual in much more detail.

7 Likes
3

Great response, I was very confused by the term “legacy” and I’m grad for your explanation. Also thanks for quoting the nixpkgs manual in that regard. It goes still a bit over my head due to the steep learning curve, but I will deep dive eventually.

It’s unfortunate that there is no easy entry into building derivations using mkDerivation. It seems you really have to understand the fundamentals to know what you are doing. I hope NixOS will evolve to make itself easier for starters and newcomers as time goes by.

I will hit the nixpkgs manual in detail.

1 Like
4

You’re looking at details which 99% people don’t need. They can just slap all dependencies into buildInputs, because they won’t cross-compile, they typically don’t need them to get propagated, etc.

5

Sorry, but I kinda have to look at these details, because my derivations don’t work. I tried to shortcut the entire thing, but now I feel I have to study a lot about the background processes to track down my issues. It just doesn’t seem so obvious, but I will get there.

6

It’d probably easier if you just posted your attempt and we tried to spot any obvious mistakes.

1 Like
7

I did. Thank you so much for looking into it. I will keep reading the documentation, but any hint is appreciated.

8

Given the slides I posted a short time ago, is this equivalency correct?

depsBuildHost == nativeBuildInputs
depsHostTarget == buildInputs
9
host → target attribute name offset
build --> build depsBuildBuild -1, -1
build --> host nativeBuildInputs -1, 0
build --> target depsBuildTarget -1, 1
host --> host depsHostHost 0, 0
host --> target buildInputs 0, 1
target --> target depsTargetTarget 1, 1
1 Like
10

The thing that confuses me about this whole topic is that in the beginning the docs say “don’t worry about ‘target’, it’s only important for certain compilers” and then presents this huge table full of ‘target’s. Absolutely doesn’t make this any clearer and I say this as a member of the documentation team.

7 Likes