Re: TuxBuild Now Supports Clang 11 and 5 new architectures

["Guillaume Tucker" <guillaume.tucker@collabora.com>]

Hi Dan,

On 17/11/2020 21:41, Dan Rue wrote:
> Cheers!
> 
> Today we've deployed support for clang-11, and we dropped support for clang 8 and 9 based on user feedback.
> 
> In addition, we have added the following architectures with gcc 8, 9, and 10:
> - s390
> - powerpc
> - sparc
> - hppa
> - sh
> 
> TuxBuild's full support matrix is as follows:
> 
>          arc arm arm64 hppa i386 mips powerpc riscv s390 sh  sparc x86_64
> clang-10 no  yes yes   no   yes  yes  no      yes   no   no  no    yes
> clang-11 no  yes yes   no   yes  yes  no      yes   no   no  no    yes

Out of interest, are there builds produced with tuxbuild for all
the supported configurations that can be downloaded with a build
log?

I've just been working on building riscv with Clang for KernelCI
and there are quite a few issues, we've dropped clang-10 as it's
actually broken.  So I wonder if you define "supported" solely by
having a Docker image and the ability to start a build, or if
it's required to actually complete a kernel build?

See related discussion about riscv here:

  https://github.com/kernelci/kernelci-core/pull/534


> gcc-10   no  yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> gcc-8    yes yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> gcc-9    yes yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> 
> We're still updating the tuxbuild documentation, but the new toolchains and architectures are available immediately without a tuxbuild update (the argument validation is all done server-side).
> 
> Now that we have TuxMake integration which is enabling these new features, we would like to add tuxmake build reproducers to tuxbuild. A build reproducer is a simple one-line shell script provided alongside the other tuxbuild artifacts, which contain the tuxmake command-line invocation to perform the same build locally. For example:
> 
>     $ cat tuxmake_reproducer.sh
>     tuxmake --runtime docker --image docker.io/tuxmake/arm64_clang-11 <http://docker.io/tuxmake/arm64_clang-11> --target-arch arm64 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y" --toolchain clang-11

That's nice but I believe it would be easier to adopt if the
syntax was simpler.  For example:

  tuxmake --runtime docker --target-arch arm64 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y" --toolchain clang-11

or if you really want to keep the docker image mentioned to
ensure reproducibility:

  tuxmake --runtime docker --image docker.io/tuxmake/arm64_clang-11 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y"

I can see why you would want to define all the parameters
explicitly, but it seems like there's some repetition there.  If
the docker image is already arch-specific, then do you also need
to specify the arch as a separate parameter?

Best wishes,
Guillaume

> As a kernel developer, would you appreciate receiving such a command as a part of a build discussion on a mailing list?
> 
> Would you send something like that to your colleagues?
> 
> Do you find the concept of a local reproducer helpful?
> 
> Thanks again to everyone using and supporting TuxBuild and TuxMake - we see you and we appreciate you,
> 
> Dan
> 
> p.s. Did you know that it's possible to perform actual reproducible builds with tuxmake? It's true. Try it for yourself, and see if your bzImage sha256sum matches:
> 
>     $ git describe
>     v5.10-rc4
>     $ tuxmake --image docker.io/tuxmake/x86_64_gcc@sha256:f8218cbfad8ecf6628fc44db864a402070feb87ff43a880e1409649172d4bc8c <http://docker.io/tuxmake/x86_64_gcc@sha256:f8218cbfad8ecf6628fc44db864a402070feb87ff43a880e1409649172d4bc8c> -r docker -k tinyconfig -e "KBUILD_BUILD_TIMESTAMP='Tue May 26 16:16:14 2020 -0500'" -e "KBUILD_BUILD_USER=tuxmake" -e "KBUILD_BUILD_HOST=tuxmake"
>     ...
>     $ sha256sum /home/drue/.cache/tuxmake/builds/634/bzImage 
>     5581ed4583fb4b9d76760ee329e248fe7281d7ea3b6ae0737efc7a6a4462affa  /home/drue/.cache/tuxmake/builds/634/bzImage
> 
> p.p.s. Did you know that tuxmake also supports podman? Just use -r podman instead of -r docker.