@dezgeg I'm not sure what the best way to test this is---I don't have access to an arm machine. Actually, everything should be cached since it's just a nix change.

@dezgeg I'd also like to make use of the exact system and config strings you used---we do have an ongoing issue that LLVM and autoconf don't see eye-to-eye on which configs are valid and what do they mean.

system is armv7l-linux with no other configuration.

Moreover, we want to move towards always passing all 3,

What is the concrete benefit of doing that in the normal (non-cross-compiling case)? To me that sounds like asking for trouble by wandering off the path tested by most people (and previous nixpkgs versions) as is evident by binutils somehow building itself in a way that actually can't link anything...

You're right in that there's no benefit in terms of the actual built derivation. But I do believe are maintainability benefits, which I attempted to lay out in #21471.

Basically, I want to excise as few code paths as possible---doing so by always falling back on the general case which is cross compilation. Assuming native builds will always be better tested---a reasonable assumption---having the less-tested cross ones differ as little as possible should minimize breakage. Also, I hope it will also reduce complexity---packages' build systems won't change, but we can just remove native-only code paths we won't use (like passing different subsets of --build --host and --target vs all 3 always).

#28325 is another instance of the same philosophy. As documented #21191, putting binaries that won't on the PATH breaks many cross builds, so we need to keep buildInputs off it for cross builds, at least. For consistency then, I want to keep it off in all cases. Here, the maintenance argument should be most concrete: right now buildInputs and nativeBuiltInputs behave identically for native builds---so your average contributor that only reads the manual in response to running into specific problems is unlikely to get it right. With the PATH change, along with say limiting the allowedRequsites to the buildInputs closure, they'll be prevented from getting it wrong.

One could argue this sounds nice in theory, but I'm basically holding native builds hostage with these sorts of changes. That's true, but the dealing with the breakage of changing these core packages is a one-time cost, but the resulting easier maintenance is ongoing.

Also, to be clear on staging, post 17.09, I want to pass all 3, which will result in having always-prefixed binaries. For 17.09, I just want to always pass --build and --host as an intermediate step.

the general case which is cross compilation.

In a theoretical sense, yes. In a practical sense, the way upstream developers write, test & debug their software is ./configure; make with no cross-compilation in sight. Similarly, that is the way how major distributions compile and package their software. Cross-compilation is way off that happy path.

Once off that path, what follows is things like 10-year-old copypasted autoconf checks that try to compile & run code bombing out with configure: error: cannot determine whether foo is bar when cross compiling. Custom-written build systems that just have a hardcoded call to gcc; well that's going to be "fun" rewriting all the makefiles. Build systems that compile C code at build time with $CC and expect to be able to run it for generating some new sources or whatever; well that's Exec format error for someone to fix.

Sure, some projects like Buildroot or Yocto do manage to cross-compile things using upstream build systems (unlike projects like Android that completely rewrite build systems of the things they're packaging). The thing is, even quite popular and core stuff needs patches to actually cross compile successfully. E.g. for Python3 in Buildroot they carry around 5 patches to fix cross compilation issues. Even worse cases seem to be Perl where they pull from an entire fork to have cross compilation work. (https://github.com/arsv/perl-cross/).

I certainly agree that #21471 and #28325 would help a lot with cross compilation. However the implications of those are (IMHO) massive and need to be discussed in https://github.com/NixOS/rfcs with the whole community. E.g. would the Perl and Python maintainers in nixpkgs now be obligated to find/develop aforementioned patches to support cross compilation? Do we have enough people who have the knowledge to debug cross compilation problems such that they actually get fixed (i.e. not having people do things like just start putting everything into nativeBuildInputs or setting configurePlatforms = [] since "that makes things work again")?

That's true, but the dealing with the breakage of changing these core packages is a one-time cost, but the resulting easier maintenance is ongoing.

Personally, I disagree here. IMO, some of the proposed changes make the build environment provided by nixpkgs diverge from what other distros provide, taking us away from the path most tested. That is, there would be a permanently increased chance of running into some problems that wouldn't have happened in a more "normal" environment.

@dezgeg Well, I'm happy to write an RFC. I hope that we can lesson any pain with a fallback a) asserting build = host = target, b) setting both sorts of inputs as equal (for PATH and allowed requisites), and c) using an unprefixed shim toolchain. This would be for packages that aren't worth getting to cross compile---but still provide benefits in that the non-support is explicit.

As to generally going against the mold, https://exherbo.org/ does basically what I am proposing, and I am told they're quite diligent about submitting upstream patches too. I hope that means for the most important stuff the road is paved, and for the less important stuff at least we wouldn't be riding it alone. CC @eternaleye who can give a better status update on that distro.

Anyways, since those changes themselves would be post 18.03 anyways, you fine with this for now? I think this is a fairly small step that's easy to change if we decide against the route I propose.

I'll note that Exherbo's approach is not "using an unprefixed shim toolchain", but rather using prefixed tools in all cases and shadowing the unprefixed commands with hard-fail commands in the build env. It used to not install them at all, but this was found to be too disruptive at the user level.

Ah right, sorry. I meant the overall "always cross" philosophy is pioneered by Exherbo, not my compromise fallback. That Exherbo hasn't needed to so fall back is a good sign!

Worried about making the 17.09 code cutoff, and @dezgeg's concerns relate more to future work post-17.09 I will write and IRC for, so I'm merging this now. Yes the motivation does stem from that future work in part, but changing one package doesn't commit us to that globally.

I hope this is OK.