[PATCH RFC next 02/18] CI: pass clang HOSTCC and CC to pytest

[Tom Rini]

On Tue, May 05, 2026 at 11:34:12AM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 5/4/26 8:05 PM, Tom Rini wrote:
> > On Mon, May 04, 2026 at 03:20:29PM +0200, Quentin Schulz wrote:
> > > From: Quentin Schulz <quentin.schulz at cherry.de>
> > > 
> > > test_env_initial_env_file test calls make on the build directory passed
> > > with --build-dir parameter which points at UBOOT_TRAVIS_BUILD_DIR which
> > > is populated with buildman before pytest is run. For "sandbox with clang
> > > test.py" and "sandbox64 with clang test.py" jobs, buildman uses clang-20
> > > toolchain, but pytest isn't configured to use that as well, resulting in
> > > gcc being used with a configuration made with clang-20 toolchain.
> > > 
> > > Specify the HOSTCC and CC clang make arguments so pytest uses the proper
> > > toolchain, this will be required in a few commits when we'll upgrade to
> > > a newer version of scripts/Makefile.extrawarn which gets rid of checking
> > > whether a clang flag exists (because it's supported by the min clang
> > > version the kernel advertises as being supported) which will be an issue
> > > since GCC for sure doesn't support all clang flags.
> > > 
> > > Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> > > ---
> > >   .gitlab-ci.yml | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > index 245e422d72f..d0ebd9f123b 100644
> > > --- a/.gitlab-ci.yml
> > > +++ b/.gitlab-ci.yml
> > > @@ -288,6 +288,7 @@ sandbox with clang test.py:
> > >       - ${HOST}
> > >     variables:
> > >       TEST_PY_BD: "sandbox"
> > > +    TEST_PY_EXTRA: "--make-args HOSTCC=clang-20 --make-args CC=clang-20"
> > 
> > Is ""--make-args 'HOSTCC=clang-20 CC=clang-20'" not parsed correctly ?
> > 
> 
> Well, this will make 'HOSTCC=clang-20 CC=clang-20' a single argument no?
> 
> Try:
> make 'HOSTCC=clang CC=clang'
> 
> Makefile doesn't like it.
> 
> If you're complaining about the need for duplicating --make-args, it's a
> choice I made when selecting the "append" action for that parameter, c.f.
> https://docs.python.org/3/library/argparse.html#action.
> 
> We could use the "extend" action with nargs=* or +, but I personally hate
> those. It'd look like something like that:
> --make-args HOSTCC=clang-20 CC=clang-20
> 
> It requires you to be aware of the special "--" argument to stop parsing of
> command options and start parsing positional arguments.

I was wondering if there was a way to avoid multiple --make-args, yes.
And I agree that switching to requiring -- to stop processing isn't an
improvement, so this is fine. Thanks for explaining.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260505/7e58b253/attachment.sig>