[v2,07/14] selftests/nolibc: defconfig: remove mrproper target

The O=/path/to/kernel-<ARCH> option allows to build kernel for different
architectures in different output directories, in this scene, it doesn't
need the mrproper operation for defconfig anymore.

If really require to clean up the source code tree, let users run the
standalone mrproper target on demand.

Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
---
 tools/testing/selftests/nolibc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Wed, Jul 19, 2023 at 09:24:54PM +0800, Zhangjin Wu wrote:
> The O=/path/to/kernel-<ARCH> option allows to build kernel for different
> architectures in different output directories, in this scene, it doesn't
> need the mrproper operation for defconfig anymore.
> 
> If really require to clean up the source code tree, let users run the
> standalone mrproper target on demand.

But that's precisely what's going to make it more and more annoying
to run simple tests. The mrproper was there precisely because one
config at a time was being used, so without it we'll restart to see
plenty of failures as it used to be before mrproper was added. I
understand what you're trying to do with the O=, but then if you're
already passing "O=", why not also pass "defconfig" ?

I mean, let's make sure this makefile is only used to manipulate
the tests. It must not become a huge wrapper for the kernel makefile
otherwise it will become extremely complicated to use to run just a
simple test. And with this one and the last few ones, I'm starting
to sense that I'll have to read a README to figure how to reliably
run a test.

In my opinion, there are mainly two use cases :
  - user, manually: commands should be short, forgiving to user
    mistakes, and easy to remember. I.e. they're compatible with
    upper-arrow, then enter.

  - scripts: these are the ones already running in loops with tons
    of variables, setting object directories with O=$arch/... and
    taking care of their own cleanups. These ones will already be
    user-specific and can very well accomodate one or two extra
    lines for a make mrproper or make defconfig if needed.

The second ones deserve thinking and control anyway. The first ones
should mostly not fail for a user mistake and in the worst case waste
a bit of their time by rebuilding something that could have been
avoided. But I do want to prioritize the user here. And that's also
why I want the makefile to be easy to read with as few macros as
possible, because once it works for you, it's easy to figure what is
being done, and how to exploit it from your scripts. The opposite is
not true. Nobody reads a makefile full of macros to try to figure how
to run their first test or why a test that worked once now fails.

Thanks,
Willy