On Fri, Oct 21, 2022 at 10:07:38AM -0700, Paul E. McKenney wrote: > > I see. In the worst case, a preliminary "make clean" will do it. We just > > need to decide what's the best solution for everyone (i.e. not waste too > > much time between tests while not getting misleading results by accident). > > Maybe just document the careful/slow way, then people doing it more > frequently can do it the clever/fast way. > > My guess is that the careful/slow is this: > > pushd tools/include/nolibc > make clean > make > popd > pushd tools/testing/selftests/nolibc > make clean > make -j32 run > > Or did I miss a turn in there somewhere? It's even easier, you don't even need the clean phase in include/nolibc. I'm doing this and it's sufficient: make -C tools/testing/selftests/nolibc clean make -C tools/testing/selftests/nolibc nolibc-test tools/testing/selftests/nolibc/nolibc-test Or for the test under QEMU, which involves a kernel build: make -C tools/testing/selftests/nolibc clean make -C tools/testing/selftests/nolibc -j $(nproc) run Where would you first look for such a hint ? Maybe the help output of the default "make" command could send as a hint that a clean is needed after patching nolibc and that could be sufficient ? I just want to make sure users don't waste their time trying to find what they could be doing wrong. Willy
