Rebased onto staging.

Then other instances of envHooks+= should be replaced as well?

Probably. There's three left:

data/misc/tzdata/tzdata-setup-hook.sh
applications/misc/gnuradio/default.nix
development/libraries/dleyna-core/setup-hook.sh

This one is the only one holding back the channel though, as far as I can see.

Thanks! Just need to make sure we use the right offset.

It is a very naïve fix. I don't know if it is the right offset.

@Ericson2314 The documentation says that "These 6 bash variables (envBuildBuildHooks etc.) correspond to the 6 sorts of dependencies by platform", but I don't understand what these sorts mean. For example, what is envBuildTargetHooks?

So env<Foo><Bar>Hooks gets applied to pkgs<Foo><Bar> only. On native it doesn't matter, for back compat, but let's not count on that!

addEnvHooks <Foo-offset> adds to each env<Foo>*Hooks, cause normally you don't care about the target platform of the dependency being mapped.

Basically, gettext is always a native build input, so use host offset for other native build inputs, or target offset for build inputs.

What is pkgsBuildTarget?

That would be things running on the build platform but compiling for the target platform. Imagine you are building a build != host != target (Canadian cross) compiler. You use a build->host compiler to build the compile itself. But you cannot use that to build the new compiler's runtime. You can't use the new compiler either cause you cannot run it. Instead you use a separate build->target compiler instead.

[Ideally we would use the new compiler to build the run time like any other library, on the host platform where thst compiler will actually run, but some compilers insist the runtime be built with the compiler that generates code using it, giving us the need for such a weird dependency.]