Add RISC-V cross-compilation target for CI #195
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "add-cross-ci"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Allows packages to be cross-compiled from x86_64 to RISC-V. For now it will only take packages that explicitly set the meta.cross attribute to true, so that they can be cross compiled. The meta.platform attribute can be also used to disable specific platforms.
For now, only ovni is marked as suitable for cross compilation, but the idea is to incrementally add more packages until all work.
9340010ea3
to59e224a8cf
59e224a8cf
toc19786a3d4
c19786a3d4
to40c8a12a34
WIP: Add RISC-V cross-compilation target for CIto Add RISC-V cross-compilation target for CIHere is a list of packages that cross compile in hydra right now: http://weasel:3001/eval/52?filter=cross&compare=46&full=#tabs-still-succeed
Also #194 should fix:
@ -100,3 +99,1 @@
cross = prev.lib.genAttrs crossTargets (target:
final.pkgsCross.${target}.bsc-ci.pkgs
);
# Native build in that platform doesn't imply cross build works
So,
meta.cross = true
is for packages that cross compile, and we know they are correct (tested to be working), right?I think for now I would keep the meaning to just: "This package will be added to the
bsc.ci.cross
target". The precise meaning is whatever we currently have set inbsc.ci.cross
, so we could add future architectures there without touching the packages. Banning a package from cross-compilation to a future arch can be controlled withmeta.badPlatforms
.In particular, it would mean that the package builds, not neccesarily that it was further tested.
Nix flake show seems to be broken since the sets get into intelPackages and linxuPackages. Not sure what changed.
I ran an eval in hydra and its building all kernel modules:
http://weasel:3001/eval/55
@ -133,0 +138,4 @@
# Direct access to package sets
tests = tests;
pkgs = bscPkgs;
inherit pkgs;
would fix the set building non top-level derivations, but maybe we want to do something else?I think building intelPackages should be fine, but callPackage adding override messes things up.
I think building derivations in intelPackages would be a good thing. But we only want to build the amd driver, not every package in linuxPackages. Not sure if recurseForDerivations could help here.
Otherwise, leaving it only for top-level packages would be ok for now.
Leaving it for top-level only.
Thanks, I think in this PR I only want to address the mechanism to mark what cross compiles and what not in the CI. We can add those in other PR to avoid noise here.
40c8a12a34
to24eec53b93
LGTM
We could consider adding a dep on all, so cross runs only on success, but since the cross set is small it should be fine.
24eec53b93
to1fba0a14a8