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 <[email protected]>
---
tools/testing/selftests/nolibc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index 9d9902b54e5e..83cb4b017bef 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -203,7 +203,7 @@ mrproper:
$(Q)$(MAKE_KERNEL) mrproper
defconfig:
- $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare
+ $(Q)$(MAKE_KERNEL) $(DEFCONFIG) prepare
menuconfig:
$(Q)$(MAKE_KERNEL) menuconfig
--
2.25.1
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
> 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.
>
Ok, let's reserve mrproper for defconfig and also for tinyconfig if we
add standalone target for it.
let's drop patch and the previous one.
Thanks,
Zhangjin
> Thanks,
> Willy