* single target builds are broken @ 2020-03-31 9:16 Vegard Nossum 2020-03-31 9:49 ` Masahiro Yamada 0 siblings, 1 reply; 5+ messages in thread From: Vegard Nossum @ 2020-03-31 9:16 UTC (permalink / raw) To: Masahiro Yamada; +Cc: Jens Axboe, LKML, linux-kbuild 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: single target builds are broken 2020-03-31 9:16 single target builds are broken Vegard Nossum @ 2020-03-31 9:49 ` Masahiro Yamada 2020-03-31 11:01 ` Vegard Nossum 0 siblings, 1 reply; 5+ messages in thread From: Masahiro Yamada @ 2020-03-31 9:49 UTC (permalink / raw) To: Vegard Nossum; +Cc: Jens Axboe, LKML, Linux Kbuild mailing list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: single target builds are broken 2020-03-31 9:49 ` Masahiro Yamada @ 2020-03-31 11:01 ` Vegard Nossum 2020-03-31 16:03 ` Masahiro Yamada 0 siblings, 1 reply; 5+ messages in thread From: Vegard Nossum @ 2020-03-31 11:01 UTC (permalink / raw) To: Masahiro Yamada; +Cc: Jens Axboe, LKML, Linux Kbuild mailing list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: single target builds are broken 2020-03-31 11:01 ` Vegard Nossum @ 2020-03-31 16:03 ` Masahiro Yamada 2020-03-31 17:56 ` Joe Perches 0 siblings, 1 reply; 5+ messages in thread From: Masahiro Yamada @ 2020-03-31 16:03 UTC (permalink / raw) To: Vegard Nossum; +Cc: Jens Axboe, LKML, Linux Kbuild mailing list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: single target builds are broken 2020-03-31 16:03 ` Masahiro Yamada @ 2020-03-31 17:56 ` Joe Perches 0 siblings, 0 replies; 5+ messages in thread From: Joe Perches @ 2020-03-31 17:56 UTC (permalink / raw) To: Masahiro Yamada, Vegard Nossum Cc: Jens Axboe, LKML, Linux Kbuild mailing list 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-03-31 17:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-31 9:16 single target builds are broken Vegard Nossum 2020-03-31 9:49 ` Masahiro Yamada 2020-03-31 11:01 ` Vegard Nossum 2020-03-31 16:03 ` Masahiro Yamada 2020-03-31 17:56 ` Joe Perches
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.