RFC: Extend cross compilation support in Hydra?

Lately I’ve been playing a lot with cross compilation. Indeed it feels like a 1st class feature of Nixpkgs! I was wondering: Every time there’s a staging-next -> master merge, I find myself cross compiling bash and other common packages which almost always cross compile successfully.

Do you think that NixOS will be interested in extending the list of pkgsCross... attributes that hydra builds by default? I think this can beneficial for advertising this feature as well. Linking armv7 Hydra channel? · Issue #222 · NixOS/infra · GitHub just in case.

Some jobs in cross-trunk (e.g. cross compiled cargo) already depend on bash, so it is likely just a matter of waiting or making sure the architecture you are using has those jobs in release-cross.nix.

2 Likes

Thanks for the reference to release-cross.nix :]. My architecture is there, and reading the *common attributes, it seems that bash should be included there, if packages like gmp, cargo and rustc are part of the common attribute set? I’m not sure though… Perhaps I evaluated a Nixpkgs revision which was too new and hydra haven’t built the packages there yet when I evaluated.

In anycase, I’d like to get some comments to the idea of adding more packages to these lists, and whether we should encourage the community to add packages there if they cross compile related packages daily…

I believe we need to redesign the way we choose which combination of Build x Host x Package to build. To me it seems prone to creating lots of combinations where I’m very doubtful about them being useful.

Recent example: do we really need 65 cross variants of rustc? Rebuilt from scratch every couple weeks? (because staging* cycles)

1 Like

I know little about rustc, but in general I think having hydra build for us the compilers that can compile to other architectures, is beneficial for all cross compiling users.

I didn’t want to go into specifics, but I believe these are cross-compiled compilers. Not compilers for cross-compiling. EDIT: choosing a compiler for an example was a bad idea.

1 Like

Oh I see what you mean. I agree! If someone is playing with cross compiling, I don’t see why would they would cross compile their machines’ compilers, and not cross compile what ever it is they want to run on those machines… However, this is debatable.

Well it is interesting for regression testing. Cross compiling a compiler can be tricky, since compiler build systems are usually quite the mess, so it is useful to check that it stays working, especially since it is not the first thing people notice breaking.

Cross compiled compilers are interesting for us e.g. as native bootstrap seeds for a new platform.

We probably only need to check it for one or two platforms though, not 65.

1 Like

What do you think about the idea of adding more development libraries to those lists? Maybe not for all platforms, but at least for raspberry pi and aarch64-linux ? Perhaps even creating a channel that will ensure cross compiling users that many basic libraries are available cross compiled already.

1 Like