more arches for clang - Githubissues

kernelci / kernelci-core

Core KernelCI tools

https://kernelci.org

GNU Lesser General Public License v2.1

104 stars 97 forks source link

more arches for clang #517

Open nickdesaulniers opened 3 years ago

nickdesaulniers commented 3 years ago

We should be able to build with clang:

[ ] malta_kvm_guest_defconfig for mips and mipsel
[ ] ppc44x_defconfig for powerpc (32b)
[ ] pseries_defconfig and powernv_defconfig for ppc64 (BE and LE respectively)
[x] #534
[ ] defconfig for s390
[x] #577

gctucker commented 3 years ago

Is this all to be built with clang 11 on linux-next?

(see my other question on #518 about mainline and the extent of the build coverage on each branch)

broonie commented 3 years ago

These all seem like reasonable targets to me, especially if we don't do any allmodconfigs which would consume lots of build resource.

Might also be worth throwing allnoconfigs in there for the ones that it works on, they're tiny and do throw up issues from time to time.

gctucker commented 3 years ago

Might also be worth throwing allnoconfigs in there for the ones that it works on, they're tiny and do throw up issues from time to time.

Yep it's there for riscv: https://github.com/kernelci/kernelci-core/pull/534/files#diff-ec5c0ba0497e23f334c288a5ca3580e72c83e4bd1eac5a6627c33c22475cc2d2R300

gctucker commented 3 years ago

@nickdesaulniers I see you're now using tuxbuild with your own CI system, so are you still looking at kernelci.org results?

nickdesaulniers commented 3 years ago

Absolutely; I have to file a bunch of bugs in our issue tracker from the latest email report. It's on my TODO list.

My goal with the various kernel CI systems is redundancy. Each service has its tradeoffs, and https://blog.travis-ci.com/oss-announcement blew up our initial CI so it's not given that any one service sticks around forever.

gctucker commented 3 years ago

OK great, thanks for confirming. Please continue to provide feedback so we can keep improving things. The KernelCI build tool is being redesigned now to become more flexible, there may be ways for Clang builds and your workflow to benefit from that.