You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How hard would it be to generate a cross compiler toolchain to allow users to cross compile to targets? For example, this would let me build defaultPackage.x86_64-darwin on linux. Or really any of the generated targets.. Doesn't seem like this is how things work right now. I see a bunch of targets generated, but I get errors when trying to cross compile to them. Would probably just be a nixpkgs override with cross system to generate different package sets for each target based on the host system. What do you guys think of this?
I don't really see how this would fit this project. The hardest part with pkgsCross in nixpkgs is that not everything builds cleanly. Derivations usually have to be patched to make things work. Which requires a good understanding of each package's inner build system.
In general, it's easier to use remote builders and build natively on all the arches.
Something that flake-utils could offer here is an alternative to eachSystem or a helper to go along with it.
As eachSystem systems builder calls builder with values from systems and then builds its own return value out of the results with a certain shape applied, a hypothetical new eachSystemAndCross systems crossSystems builder could call builder with values from systems and crossSystems and then build its own return value out of the results - perhaps with a shape mirroring that of nixpkgs (where cross results are available somewhere beneath pkgsCross).
eachSystemAndCross might not be the right name/shape for this but I think it's an example of how flake-utils could offer an API that helps set up cross-compilation without concerning itself with whether any particular packages in nixpkgs can successfully be cross-compiled for a given system or not (that remains the flake author's problem to solve).
In general, it's easier to use remote builders and build natively on all the arches.
Building for musl is a good example of a cross build that's not really any better on a remote builder
Similarly, builds against Bionic (another alternate C library) for Android (I don't imagine setting up and using a remote Android builder would be much fun, even if it is probably not technically impossible).
Activity
zimbatm commentedon May 18, 2021
I don't really see how this would fit this project. The hardest part with
pkgsCrossin nixpkgs is that not everything builds cleanly. Derivations usually have to be patched to make things work. Which requires a good understanding of each package's inner build system.In general, it's easier to use remote builders and build natively on all the arches.
psionic-k commentedon Nov 11, 2021
Building for musl is a good example of a cross build that's not really any better on a remote builder
exarkun commentedon Dec 7, 2022
Something that flake-utils could offer here is an alternative to
eachSystemor a helper to go along with it.As
eachSystem systems buildercallsbuilderwith values fromsystemsand then builds its own return value out of the results with a certain shape applied, a hypothetical neweachSystemAndCross systems crossSystems buildercould callbuilderwith values fromsystemsandcrossSystemsand then build its own return value out of the results - perhaps with a shape mirroring that of nixpkgs (where cross results are available somewhere beneathpkgsCross).eachSystemAndCrossmight not be the right name/shape for this but I think it's an example of how flake-utils could offer an API that helps set up cross-compilation without concerning itself with whether any particular packages in nixpkgs can successfully be cross-compiled for a given system or not (that remains the flake author's problem to solve).Similarly, builds against Bionic (another alternate C library) for Android (I don't imagine setting up and using a remote Android builder would be much fun, even if it is probably not technically impossible).