On Wed, Mar 02, 2022 at 02:15:45PM -0700, Nathan Chancellor wrote: > Sounds good, tentative patch attached, it passes all of my testing. > There is an instance of $(LLVM) in tools/testing/selftests/lib.mk that I > did not touch, as that will presumably have to go through the selftests > tree. I can send a separate patch for that later. I think it's fine to include that here, just to keep the logic together. > Peter, is this approach okay with you? If so, would you like to be > co-author or should I use a suggested-by tag? > > Cheers, > Nathan > From 83219caafbb7dbc2e41e3888ba5079d342aff633 Mon Sep 17 00:00:00 2001 > From: Nathan Chancellor <nathan@xxxxxxxxxx> > Date: Wed, 2 Mar 2022 13:28:14 -0700 > Subject: [PATCH] kbuild: Allow a suffix with $(LLVM) > > The LLVM variable allows a developer to quickly switch between the GNU > and LLVM tools. However, it does not handle versioned binaries, such as > the ones shipped by Debian, as LLVM=1 just defines the build variables > with the unversioned binaries. > > There was some discussion during the review of the patch that introduces > LLVM=1 around this, ultimately coming to the conclusion that developers > can just add the folder that contains the unversioned binaries to their > PATH, as Debian's versioned suffixed binaries are really just symlinks > to the unversioned binaries in /usr/lib/llvm-#/bin: > > $ realpath /usr/bin/clang-14 > /usr/lib/llvm-14/bin/clang > > $ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1 > > However, it is simple enough to support this scheme directly in the > Kbuild system by allowing the developer to specify the version suffix > with LLVM=, which is shorter than the above suggestion: > > $ make ... LLVM=-14 > > It does not change the meaning of LLVM=1 (which will continue to use > unversioned binaries) and it does not add too much additional complexity > to the existing $(LLVM) code, while allowing developers to quickly test > their series with different versions of the whole LLVM suite of tools. > > Signed-off-by: Nathan Chancellor <nathan@xxxxxxxxxx> I like it! Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
