<infinisil>
I agree with srhb, cross compilation probably shouldn't be part of nix itself
<noonien>
hmm
<noonien>
being quite new, i'm unsure where nix ends and nixpkgs begins tbh
<srhb>
cross compilation, just as compilation, is really an artifact of various compiler flags, libraries, etc.
<srhb>
nix should not know anything about any of that.
<srhb>
It would hugely complicate matters
<noonien>
but, being a package manager at heart, i think quite of few things in nixpkgs might belong with nix instead of nixpkgs
<infinisil>
Nix, the language, is only really responsible for combining everything together, what commands are being run in the build and what arch target they're for doesn't have anything to do with that
<srhb>
I can sort of agree with things that makes nix the language easier to use
<infinisil>
(Nix does have builtins.currentPlatform though, which you need to have appropriate build commands on the different platforms)
<infinisil>
currentSystem*
<infinisil>
> builtins.currentSystem
<{^_^}>
"x86_64-linux"
<noonien>
i don't like to bring other tools as comparison, especially since this solves entirely different problems, but having fought and given up on cross-compilation multiple times, because each build systemm has its own unique/special/complex way of dealing with it, i love how simple it is to do in go
<infinisil>
Hmm, but go is like on a different abstraction layer
<noonien>
i understand it's not as easy, even reading about `*Inputs` gave me a headache, but cross-compilation seems to be more and more useful
<infinisil>
Hmm
<noonien>
especially with how popular arm platforms have become, maybe even riscv at some point
<infinisil>
But let's imagine Nix gets "support" for cross compilation, what would that mean in the end? How will it look like?
<noonien>
for a user? or a package maintainer?
<srhb>
Both, ideally. :-P
<infinisil>
Both
kyren has joined #nix-lang
<noonien>
well, for a user, i image it wold be easiest just to provide a configuration option
<infinisil>
Okay so we include cross compilation in nix itself, how can we enforce that stuff gets cross compiled? We need to pass special flags to gcc, for other compilers it might just not work at all (it's not a given that a compiler supports that).
<noonien>
for example, "i want to build the sdimage described by this nix expression, but for n armv6l target system"
<infinisil>
Oh, but then we need to include gcc itself in nix itself
<infinisil>
ANd all the compilers too
<noonien>
as a package maintainer, idealy, nothing would be different
<noonien>
apart from compiler packages
<infinisil>
So Nix would have to gain support for all those buildGoPackage, mkDerivation, ...
<srhb>
noonien: What you're describing is basically what we have in nixpkgs.
<noonien>
yes, things that do the actual building should implement cross-compilation
<srhb>
noonien: Well, sure, that makes our job easier :)
<noonien>
currently, from what i gather, cross-compilation is not impossible, just a problem that each user has to deal with currently
<srhb>
noonien: Skipping over "option" which I think is really bad compared to explicit trees in nixpkgs, what we have now is...
<srhb>
nix-build . -A pkgsCross.target.hello
<srhb>
like, say nix-build . -A pkgsCross.mingw32.hello
<noonien>
hmm, why not `nix-build . -A pkgs.hello --target armv6l-linux-gnueabihf`?
<srhb>
(The reason I dislike options is that they come dangerously close to impurities to the perspective of the supporter. You give a person an expression that works for you, they realize it doesn't work, you go: ok, give me your configuration...)
<srhb>
noonien: Well.. I think we may have just a philosphical difference here, but in the end my answer boils down to "I'd like the nixpkgs commit hash to be solely determining what happens when I build a package" -- in most situations
<srhb>
No flags, no config files.
<srhb>
The more sources of information that go into the drv, the harder it is to make it easily reproducible.
<noonien>
Hmm, so packages should be packaged differently for each platform?
<srhb>
noonien: They're not!
<srhb>
noonien: pkgsCross.$target.* is the exact same package definitions as pkgs.*
<srhb>
They switcheroo just the various stdenvs needed for cross :)
ddellacosta has joined #nix-lang
<noonien>
well, sure, i wouldn't mind that
<srhb>
That's what we have!
<srhb>
You can literally build a windows version of hello with the above command.
<noonien>
i wouldn't even mind having only a set of built-in archs that work tbh
<noonien>
however, i recently tried to get nixos to run on an armv6l target and couldn't build an image from my x86_64 machine
<infinisil>
It just doesn't make sense though, there's no builtin that can control build commands, this is very much out of scope of the language itself
<infinisil>
However, what would work
<infinisil>
Is to have a repository github.com/NixOS/nix-builders
<infinisil>
Which could contain all the infrastructure for compilers and builders
<infinisil>
Without any package definitions (beyond the compilers)
<infinisil>
And that could then have support for cross comp. nixpkgs would then depend on that repo
<srhb>
I like the idea of splitting out "stdenvs" for sure..
<noonien>
hmm
<noonien>
given pkgsCross, could one share configuration.nix across machines with different arches?
<srhb>
noonien: pkgsCross has nothing to do with that, and you already can.
<noonien>
or would that imply passing the correct pkgs from a specific point?
<srhb>
pkgs is always correct from the native perspective.
<srhb>
(because it uses builtins.currentSystem)
<noonien>
hmmm
<noonien>
so there would be no changes to configuration.nix to work on multiple platforms?
<srhb>
Indeed.
<noonien>
hmm, if not, doesn't that kindof go against pkgsCross?
<srhb>
Nope.
<srhb>
pkgsCross is for when your target differs from currentSystem
<noonien>
Yes, but you get different outputs depending on the target you're compiling for, given the exact same package state
<srhb>
Yes, but pkgs.hello also has different inputs depending on what the system is in "pkgs" :)
<noonien>
i was refering to
<noonien>
> (The reason I dislike options is that they come dangerously close to impurities to the perspective of the supporter. You give a person an expression that works for you, they realize it doesn't work, you go: ok, give me your configuration...)
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):220:168
<srhb>
noonien: Yes, and this _is_ indeed an impurity that we live with
<noonien>
so, providing my configuration is not longer the only requirement, you already have to specify the target machine you're building on
<srhb>
in fact, the entry point is pkgs/top-level/impure.nix
<srhb>
noonien: I'm not sure I follow. In pkgsCross we explicitly ignore currentSystem on the target side.
<infinisil>
noonien: Related, there is a --pure-eval option to nix which avoids *all* impurities
<srhb>
In pkgs, we use currentSystem for the target side as well, roughly.
<srhb>
noonien: You could totally argue that the system impurity in pkgs is bad, but then you could no longer use the same configuration.nix on different systems without at least specifying the system for pkgs in each case.
<srhb>
I might even be inclined to agree with you, slightly, for a few minutes, and then I'd get really lazy and say naaahhh I like *this* impurity and pretend my ethics are clean :-)
<infinisil>
srhb: Idea: Make nix print the impure inputs from pkgs/top-level/impure.nix when it builds something
<noonien>
I guess what i'm arguing for is the ability to set `builtins.currentSystem` and having everything just work, even though hostSystem != `builtins.currentSystem`
<noonien>
This would not change how it currently works
<srhb>
infinisil: Yes!
<noonien>
I apologise again, i'm not completely versed in nix terminology or design, i'm unsure what `pure` means in nix's case.
<srhb>
noonien: Pure in this sense means that the environment doesn't affect the nix expression in any way.
<noonien>
Hmm, how would this be possible for packages that require compilation to a specific target, even if it's `builtins.currentSystem`. My intuition would be that only platform-agnostic packages can be pure, maybe.
<srhb>
Right, that's why we have that one impurity I mentioned above.
<srhb>
(We have others, but those I agree less with)
<noonien>
I think i understand, the impurity is choosing what system to compile for, but since this is passed down, the other derivations are not considered impure?
<srhb>
noonien: Usually not. But it's a matter of taste and feeling and empirical knowledge of how much confusion it causes.