On Tue, Mar 31, 2020 at 8:02 PM Vegard Nossum <vegard.nossum@xxxxxxxxxx> wrote: > > > On 3/31/20 11:49 AM, Masahiro Yamada wrote: > > On Tue, Mar 31, 2020 at 6:16 PM Vegard Nossum <vegard.nossum@xxxxxxxxxx> wrote: > >> > >> > >> Hi, > >> > >> I often run 'make foo/bar.o' as part of my workflow, even when bar.o is > >> not specified in any kernel makefile, and this has worked just fine for > >> years. > >> > >> This is broken after commit 394053f4a4b3e3eeeaa67b67fc886a9a75bd9e4d > >> (kbuild: make single targets work more correctly) and just gives an error: > >> > >> $ make kernel/test.o > >> CALL scripts/checksyscalls.sh > >> CALL scripts/atomic/check-atomics.sh > >> DESCEND objtool > >> make[2]: *** No rule to make target 'kernel/test.o'. Stop. > >> scripts/Makefile.build:502: recipe for target '__build' failed > >> make[1]: *** [__build] Error 2 > >> Makefile:1670: recipe for target 'kernel' failed > >> make: *** [kernel] Error 2 > > > > > > This is intentional to make the single target builds > > work in the same manner as the normal builds. > > > > > > The necessary CONFIG dependency must be met. > > > > obj-$(CONFIG_FOO) += foo.o > > > > foo.o can be built only when CONFIG_FOO is y/m. > > > > > > > >> For top-level objects (e.g. 'make bar.o') the situation is even worse, > >> since make exits with status 0 without building anything :-/ > > > > > > There is no .c or .S file at the top-level of the kernel source tree. > > > > 'make bar.o' never happens. > > It doesn't happen in mainline, but I often use that to small test things > in an isolated source file. As just one example you can do > > #include <linux/sched.h> > unsigned int task_struct_size = sizeof(struct task_struct); > > and then you can look in the object file to find the size. Or any other > of a million useful things that you might want to do without rebuilding > an actual source file or modifying makefiles. > > >> Is there any chance we can get this back? It was super useful for me. > > > > > > What you want is "Let's build whatever", right? > > It's really useful to be able to build object files separately, but as > if it was part of the kernel (so e.g. with all the gcc flags, include > paths, etc.). > > > No, please add 'obj-y += test.o' if you want to > > test your local file. > > This is a clear workflow regression for me. Why is it so absolutely > necessary to break the way it used to work? Because this is the only way to do this correctly. Previously, 'make foo/bar/baz.o' descended into foo/bar (it always assumed there was Makefile in the directory part) So, there were lots of cases where single builds did not work: https://www.spinics.net/lists/linux-kbuild/msg21921.html The way to do this correctly is to descend directories one by one, parsing Makefiles. With no entry in obj-y/m, Kbuild cannot determine where to build that object. > At the very least, can we find a way to reduce the typing overhead for > testing one-offs like that? 'make STANDALONE=1 test.o' or something? Probably, I do not want to do this. Supporting everybody's demand is not a good idea. So, I draw a line somewhere. Saving some typing is less important. > > > Vegard -- Best Regards Masahiro Yamada
