[PATCH] kbuild: uapi: reuse KBUILD_USERCFLAGS

[PATCH] kbuild: uapi: reuse KBUILD_USERCFLAGS

[Thomas Weißschuh]

The toplevel Makefile already provides the compiler flags necessary to
build userspace applications for the target.

Make use of them instead of duplicating the logic.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 usr/include/Makefile | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/usr/include/Makefile b/usr/include/Makefile
index 61a7dd4fc05f004d785c64c0019ad846c84719d5..d8a508042fed315401ed689e0839af249c4b31c8 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -6,16 +6,9 @@
 #
 # -std=c90 (equivalent to -ansi) catches the violation of those.
 # We cannot go as far as adding -Wpedantic since it emits too many warnings.
-UAPI_CFLAGS := -std=c90 -Wall -Werror=implicit-function-declaration
+UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration
 
-# In theory, we do not care -m32 or -m64 for header compile tests.
-# It is here just because CONFIG_CC_CAN_LINK is tested with -m32 or -m64.
-UAPI_CFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
-
-# USERCFLAGS might contain sysroot location for CC.
-UAPI_CFLAGS += $(USERCFLAGS)
-
-override c_flags = $(UAPI_CFLAGS) -Wp,-MMD,$(depfile) -I $(obj) -I $(srctree)/usr/dummy-include
+override c_flags = $(KBUILD_USERCFLAGS) $(UAPI_CFLAGS) -Wp,-MMD,$(depfile) -I $(obj) -I $(srctree)/usr/dummy-include
 
 # The following are excluded for now because they fail to build.
 #

---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251013-kbuild-uapi-usercflags-affb222af087

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Re: [PATCH] kbuild: uapi: reuse KBUILD_USERCFLAGS

[Nathan Chancellor]

On Tue, Oct 14, 2025 at 07:55:32AM +0200, Thomas Weißschuh wrote:
> The toplevel Makefile already provides the compiler flags necessary to
> build userspace applications for the target.
> 
> Make use of them instead of duplicating the logic.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---

Seems reasonable to me.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

>  usr/include/Makefile | 11 ++---------
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/usr/include/Makefile b/usr/include/Makefile
> index 61a7dd4fc05f004d785c64c0019ad846c84719d5..d8a508042fed315401ed689e0839af249c4b31c8 100644
> --- a/usr/include/Makefile
> +++ b/usr/include/Makefile
> @@ -6,16 +6,9 @@
>  #
>  # -std=c90 (equivalent to -ansi) catches the violation of those.
>  # We cannot go as far as adding -Wpedantic since it emits too many warnings.
> -UAPI_CFLAGS := -std=c90 -Wall -Werror=implicit-function-declaration
> +UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration
>  
> -# In theory, we do not care -m32 or -m64 for header compile tests.
> -# It is here just because CONFIG_CC_CAN_LINK is tested with -m32 or -m64.
> -UAPI_CFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> -
> -# USERCFLAGS might contain sysroot location for CC.
> -UAPI_CFLAGS += $(USERCFLAGS)
> -
> -override c_flags = $(UAPI_CFLAGS) -Wp,-MMD,$(depfile) -I $(obj) -I $(srctree)/usr/dummy-include
> +override c_flags = $(KBUILD_USERCFLAGS) $(UAPI_CFLAGS) -Wp,-MMD,$(depfile) -I $(obj) -I $(srctree)/usr/dummy-include
>  
>  # The following are excluded for now because they fail to build.
>  #
> 
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20251013-kbuild-uapi-usercflags-affb222af087
> 
> Best regards,
> -- 
> Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 

Re: [PATCH] kbuild: uapi: reuse KBUILD_USERCFLAGS

[Nicolas Schier]

On Tue, 14 Oct 2025 07:55:32 +0200, Thomas Weißschuh wrote:
> The toplevel Makefile already provides the compiler flags necessary to
> build userspace applications for the target.
> 
> Make use of them instead of duplicating the logic.
> 
> 

Applied to kbuild-next, thanks!

[1/1] kbuild: uapi: reuse KBUILD_USERCFLAGS
      commit: ac1280211e1c41704c756fd1bc5512f92010b3f0

Please note that commit hashes might change in case of issues with
kbuild-next branch.

Best regards,
-- 
Nicolas