Re: single target builds are broken

[Masahiro Yamada]

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