So eventually I'd like to prevent / whitelist packages packages from depending on these attributes, but I'll relent for now.

As a first step, we can move this into an overlay and have the tarballs job do a build without.

Why? The concept is clearly useful for some packages (granted, not many of them).

Yes xbursttools is the only one now using it but it definitely makes sense in that case.

The use cases I know are roughly:

• firmware flashers depending on cross-built firmware packages (e.g. U-Boot or Trusted Firmware): xbursttools as mentioned, odroid-xu3-bootloader could be using it already, tegra-uboot-flasher if I ever get around to packaging it
• QEMU/other emulators for those same firmware packages
• U-Boot on aarch64 might need a ARM cross compiler for some boards in the future
• Also for an U-Boot dev shell you need a cross compiler for all of the 10+ architectures it supports
• Kernel on aarch64 might need a ARM cross compiler (this is a tough choice since in native builds on aarch64 the native ARM compiler could be run on some machines, but not for example on the ThunderX machine we currently have on Hydra) in the future/depending on some config options
• Embedded environments like the Arduino IDE need the AVR / ARM cross compiler + libc (if it's a good idea to un-vendor those in the first place)

Also stdenv_32bit and callPackage_i686 which are conceptually similar are used for many things.

@dezgeg That's fine. I guess my fear is people that try to pull the cross tools out from this pkgsCross.xxx.buildPackages to build a cross-compiled executable or binary, when you should package the library normally, and then pull it itself out of pkgsCross.xxx. Put differently, if a package consists of components for different architectures, it's highly advantageous to build those in separate derivations.

Whatever naming used would be good to settle on quickly to avoid breaking or need for compatibility aliases. Thanks for working on this, all!

@Ericson2314 Well, requesting upstreams to make major changes to their build systems to have objects built for different architectures built separately isn't something we should do, but rather accommodate what they need.

For instance, as an U-Boot developer, let's say I'm hacking on some of the 64-bit Allwinner boards that some day in the future might have parts of the early boot code written in ARM code (thus requiring an ARM compiler) due to space constraints. To me it would be a complete implementation detail whether the early boot code is ARM or aarch64, all that I want or need is that make pine64_defconfig; make all compiles the thing from scratch when hacking on it, just like it does with any other board U-Boot supports.

@dezgeg Yeah I'm relenting :). For certain compilers I do think it's worth it to change upstream, but yes I completely agree with you for these bare-metal cases where the idea of a single host platform breaks down.