On 2024-08-03 11:45:30+0000, Willy Tarreau wrote: > On Sun, Jul 28, 2024 at 12:10:03PM +0200, Thomas Weißschuh wrote: > > Makefile.include can modify CC and CFLAGS for usage with clang. > > Make use of it. > > > > Signed-off-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx> > > --- > > tools/testing/selftests/nolibc/Makefile | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > index 8000bc3c408b..cdff317c35f2 100644 > > --- a/tools/testing/selftests/nolibc/Makefile > > +++ b/tools/testing/selftests/nolibc/Makefile > > @@ -155,6 +155,9 @@ CFLAGS ?= -Os -fno-ident -fno-asynchronous-unwind-tables -std=c89 -W -Wall -Wex > > $(CFLAGS_$(XARCH)) $(CFLAGS_STACKPROTECTOR) $(CFLAGS_EXTRA) > > LDFLAGS := > > > > +# Modify CFLAGS based on LLVM= > > +include $(srctree)/tools/scripts/Makefile.include > > I'm confused, doesn't it precisely undo the previous patch, which > said that we ought not to include Makefile.include as it makes it > harder for LLVM ? The previous inclusion doesn't make it harder. The problem is that Makefile.include does two things 1) objtree setup and 2) LLVM handling. For 1) we want to include it as early as possible, necessarily before using $(objtree). For 2) we need to include it after "CFLAGS ?=". Reshuffling the Makefile to satisfy both requirements will look bad. So the first commit removed the usage of Makefile.include for 1) because that is easy to do and the second commit includes it later to satisfy 2). > If so, I suspect that both commits should be squashed with a better > explanation for both operations at once (e.g. maybe "move makefile > inclusion later to benefit from LLVM=..." etc). Ack.
