Use the `BINDGEN_EXTRA_CLANG_ARGS` environment variable to pass the
`--target` option for cross compiling, so that the function can be used
to test both bindgen options and bindgen backend options.

Signed-off-by: Asuna Yang <SpriteOvO@gmail.com>
---
 scripts/Kconfig.include | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e803..a8cfe9f408a5 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -75,3 +75,8 @@ rustc-llvm-version := $(shell,$(srctree)/scripts/rustc-llvm-version.sh $(RUSTC))
 # If you are testing for unstable features, consider testing RUSTC_VERSION
 # instead, as features may have different completeness while available.
 rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null --out-dir=.tmp_$$ -o .tmp_$$/tmp.rlib)
+
+# $(rust-bindgen-option,<flag>)
+# Return y if the Rust bindgen supports <flag>, n otherwise
+# To test options for the bindgen backend, add -- at the beginning, for example: $(rust-bindgen-option,-- <backend-flag>)
+rust-bindgen-option = $(success,trap "rm -f .tmp_$$.h" EXIT; touch .tmp_$$.h; BINDGEN_EXTRA_CLANG_ARGS+=" --target=$(BINDGEN_TARGET)" $(BINDGEN) .tmp_$$.h $(1))

-- 
2.51.1

On Mon, Nov 24, 2025 at 1:23 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> Use the `BINDGEN_EXTRA_CLANG_ARGS` environment variable to pass the
> `--target` option for cross compiling, so that the function can be used
> to test both bindgen options and bindgen backend options.

It seems this explains part of how it works, but not what the commit
adds and why, i.e. could we start with "Add `rustc-bindgen-option`..."
etc.?

By the way, shouldn't this just be called `bindgen-option`? Up to the
Kbuild team.

More importantly, should we just have a separate function for backend
flags? That would be easier and would avoid having to use the
environment variable, if I understand the commit message here
correctly. And, anyway, it is actually the only function we need so
far.

> +# Return y if the Rust bindgen supports <flag>, n otherwise

Maybe just "y if bindgen supports"?

Thanks!

Cheers,
Miguel

On 11/24/25 9:48 AM, Miguel Ojeda wrote:
> More importantly, should we just have a separate function for backend
> flags? That would be easier and would avoid having to use the
> environment variable, if I understand the commit message here
> correctly. And, anyway, it is actually the only function we need so
> far.

You are right, separated might be better.

Another reason is, in `scripts/Makefile.compiler`, there is a set of 
functions with the same name provided for use by Makefile. Since we 
currently do not need to check for bindgen options in Makefile, I didn't 
add function for bindgen there. If we add it in the future, the 
`bindgen-option` function in `Kconfig.include` will correspond to the 
`bindgen-option-yn` function in `Makefile.compiler`, and 
`bindgen-option` function in `Makefile.compiler` will return the 
selected option instead of yn.

If we don't separate them now, for consistency, in `Makefile.compiler`, 
`$(call bindgen-option,-- --some-flag-a,-- --some-flag-b)` will return 
an option prefixed with --, which makes it difficult to use.

I will separate them into two functions in the next revision, 
`bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`? 
Which one do you prefer?).

On Mon, Nov 24, 2025 at 3:42 AM Asuna Yang <spriteovo@gmail.com> wrote:
>
> I will separate them into two functions in the next revision,
> `bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`?
> Which one do you prefer?).

If we don't need `bindgen-option` (the normal one I mean) so far,
perhaps we should skip it. On the other hand, `rustc-option-yn` is
there and is not used either (it was added for consistency). Up to the
Kbuild team, I guess.

As for the name, no strong preference. `bindgen-backend-option` sounds
good, but `bindgen-cc-option` is more consistent with `cc-option` and
probably easier to understand for people new to `bindgen`, and anyway
the flags we pass there wouldn't make sense if the backend is not a C
compiler.

Thanks!

Cheers,
Miguel

On Mon, Nov 24, 2025 at 04:08:36AM +0100, Miguel Ojeda wrote:
> On Mon, Nov 24, 2025 at 3:42 AM Asuna Yang <spriteovo@gmail.com> wrote:
> >
> > I will separate them into two functions in the next revision,
> > `bindgen-option` and `bindgen-backend-option` (or `bindgen-cc-option`?
> > Which one do you prefer?).
> 
> If we don't need `bindgen-option` (the normal one I mean) so far,
> perhaps we should skip it. On the other hand, `rustc-option-yn` is
> there and is not used either (it was added for consistency). Up to the
> Kbuild team, I guess.

I do not have a strong preference one way or the other. These macros
tend to be low maintenance and do not take up much space regardless so
preemptively adding it so that it is ready for use in the future is no
big deal in my opinion.

> As for the name, no strong preference. `bindgen-backend-option` sounds
> good, but `bindgen-cc-option` is more consistent with `cc-option` and
> probably easier to understand for people new to `bindgen`, and anyway
> the flags we pass there wouldn't make sense if the backend is not a C
> compiler.

Yeah, I think either one sort of requires knowledge of bindgen to know
the difference between a flag to bindgen and a flag to the C compiler
behind bindgen so no strong preference from my side (Nicolas may feel
differently).

Cheers,
Nathan