single target builds are broken

single target builds are broken

[Vegard Nossum]

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

For top-level objects (e.g. 'make bar.o') the situation is even worse,
since make exits with status 0 without building anything :-/

Is there any chance we can get this back? It was super useful for me.


Vegard

Re: single target builds are broken

[Masahiro Yamada]

On Tue, Mar 31, 2020 at 6:16 PM Vegard Nossum <vegard.nossum@oracle.com> 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.



> Is there any chance we can get this back? It was super useful for me.


What you want is "Let's build whatever", right?

No, please add 'obj-y += test.o' if you want to
test your local file.


-- 
Best Regards
Masahiro Yamada

Re: single target builds are broken

[Vegard Nossum]

On 3/31/20 11:49 AM, Masahiro Yamada wrote:
> On Tue, Mar 31, 2020 at 6:16 PM Vegard Nossum <vegard.nossum@oracle.com> 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?

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?


Vegard

Re: single target builds are broken

[Masahiro Yamada]

On Tue, Mar 31, 2020 at 8:02 PM Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
>
> On 3/31/20 11:49 AM, Masahiro Yamada wrote:
> > On Tue, Mar 31, 2020 at 6:16 PM Vegard Nossum <vegard.nossum@oracle.com> 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

Re: single target builds are broken

[Joe Perches]

On Wed, 2020-04-01 at 01:03 +0900, Masahiro Yamada wrote:
> On Tue, Mar 31, 2020 at 8:02 PM Vegard Nossum <vegard.nossum@oracle.com> wrote:
> > 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.).
[]
> 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.

I too find this regression less than desirable.

make <single_object> is/was quite useful even
if it didn't always work.