[1/1] kernel.bbclass: remove explicit version.h target

Submitted by Bruce Ashfield on Oct. 18, 2012, 2:47 p.m.

Details

Message ID 7b8c12ae454f69996f935aef35cccc6d352b0964.1350571171.git.bruce.ashfield@windriver.com
State Accepted
Commit 4211de44e093f698604bbbb6c6ad70f63893cc14
Headers show

Commit Message

Bruce Ashfield Oct. 18, 2012, 2:47 p.m.
The compilation routine for the kernel has an explicit call to
build version.h, which works fine for most kernels, but the
location of it has recently changes.

commit d183e6f5 [UAPI: Move linux/version.h]
commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
                 header installation and checking]

moves the file to include/generated/linux/version.h and then to
include/generated/uapi/linux/version.h.

As a result kernel builds of 3.7 or bisection builds of intermediate
kernel commits will fail with:

  make[2]: *** No rule to make target `include/linux/version.h'.  Stop.

Making the explicit version.h build conditional on the version, or
via a file test would fix the problem, but it introduces some complexity
to the build.

Even without an explicit call to build version.h, it is always produced
by the kernel build, so it can simply be removed.

Note: it isn't clear why the explicit build of version.h was originally
required, but the prep phases of the kernel have changed significantly,
so it should no longer be required.

[YOCTO: #3293]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel.bbclass |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 0df8f08..2163c1f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -85,7 +85,6 @@  KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.g
 
 kernel_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
-	oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}"
 	oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}"
 	if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then
 		gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"

Comments

Darren Hart Oct. 18, 2012, 2:53 p.m.
On 10/18/2012 10:47 AM, Bruce Ashfield wrote:
> The compilation routine for the kernel has an explicit call to
> build version.h, which works fine for most kernels, but the
> location of it has recently changes.
> 
> commit d183e6f5 [UAPI: Move linux/version.h]
> commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
>                  header installation and checking]
> 
> moves the file to include/generated/linux/version.h and then to
> include/generated/uapi/linux/version.h.
> 
> As a result kernel builds of 3.7 or bisection builds of intermediate
> kernel commits will fail with:
> 
>   make[2]: *** No rule to make target `include/linux/version.h'.  Stop.
> 
> Making the explicit version.h build conditional on the version, or
> via a file test would fix the problem, but it introduces some complexity
> to the build.
> 
> Even without an explicit call to build version.h, it is always produced
> by the kernel build, so it can simply be removed.
> 
> Note: it isn't clear why the explicit build of version.h was originally
> required, but the prep phases of the kernel have changed significantly,
> so it should no longer be required.


How far back have you tested with? 3.0? If it works back to 3.0, then
I'd argue it's just fine.

--
Darren


> 
> [YOCTO: #3293]
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel.bbclass |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 0df8f08..2163c1f 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -85,7 +85,6 @@ KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.g
>  
>  kernel_do_compile() {
>  	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> -	oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}"
>  	oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}"
>  	if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then
>  		gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"
>
Richard Purdie Oct. 18, 2012, 3:12 p.m.
On Thu, 2012-10-18 at 10:47 -0400, Bruce Ashfield wrote:
> The compilation routine for the kernel has an explicit call to
> build version.h, which works fine for most kernels, but the
> location of it has recently changes.
> 
> commit d183e6f5 [UAPI: Move linux/version.h]
> commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
>                  header installation and checking]
> 
> moves the file to include/generated/linux/version.h and then to
> include/generated/uapi/linux/version.h.
> 
> As a result kernel builds of 3.7 or bisection builds of intermediate
> kernel commits will fail with:
> 
>   make[2]: *** No rule to make target `include/linux/version.h'.  Stop.
> 
> Making the explicit version.h build conditional on the version, or
> via a file test would fix the problem, but it introduces some complexity
> to the build.
> 
> Even without an explicit call to build version.h, it is always produced
> by the kernel build, so it can simply be removed.
> 
> Note: it isn't clear why the explicit build of version.h was originally
> required, but the prep phases of the kernel have changed significantly,
> so it should no longer be required.

I had a look through the archives. I think this is a throwback to 2.4,
we had to build the version.h file to figure out if we had a 2.6 or a
2.4 kernel, then we could do the right thing to build it.

Since we don't support 2.4 anymore, this can die!

Cheers,

Richard
Bruce Ashfield Oct. 18, 2012, 4:35 p.m.
On 12-10-18 11:12 AM, Richard Purdie wrote:
> On Thu, 2012-10-18 at 10:47 -0400, Bruce Ashfield wrote:
>> The compilation routine for the kernel has an explicit call to
>> build version.h, which works fine for most kernels, but the
>> location of it has recently changes.
>>
>> commit d183e6f5 [UAPI: Move linux/version.h]
>> commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
>>                   header installation and checking]
>>
>> moves the file to include/generated/linux/version.h and then to
>> include/generated/uapi/linux/version.h.
>>
>> As a result kernel builds of 3.7 or bisection builds of intermediate
>> kernel commits will fail with:
>>
>>    make[2]: *** No rule to make target `include/linux/version.h'.  Stop.
>>
>> Making the explicit version.h build conditional on the version, or
>> via a file test would fix the problem, but it introduces some complexity
>> to the build.
>>
>> Even without an explicit call to build version.h, it is always produced
>> by the kernel build, so it can simply be removed.
>>
>> Note: it isn't clear why the explicit build of version.h was originally
>> required, but the prep phases of the kernel have changed significantly,
>> so it should no longer be required.
>
> I had a look through the archives. I think this is a throwback to 2.4,
> we had to build the version.h file to figure out if we had a 2.6 or a
> 2.4 kernel, then we could do the right thing to build it.
>
> Since we don't support 2.4 anymore, this can die!

That makes my day.

Should I resend, or is the RFC patch enough ?

Bruce

>
> Cheers,
>
> Richard
>
Saul Wold Oct. 19, 2012, 9:24 p.m.
On 10/18/2012 09:35 AM, Bruce Ashfield wrote:
> On 12-10-18 11:12 AM, Richard Purdie wrote:
>> On Thu, 2012-10-18 at 10:47 -0400, Bruce Ashfield wrote:
>>> The compilation routine for the kernel has an explicit call to
>>> build version.h, which works fine for most kernels, but the
>>> location of it has recently changes.
>>>
>>> commit d183e6f5 [UAPI: Move linux/version.h]
>>> commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
>>>                   header installation and checking]
>>>
>>> moves the file to include/generated/linux/version.h and then to
>>> include/generated/uapi/linux/version.h.
>>>
>>> As a result kernel builds of 3.7 or bisection builds of intermediate
>>> kernel commits will fail with:
>>>
>>>    make[2]: *** No rule to make target `include/linux/version.h'.  Stop.
>>>
>>> Making the explicit version.h build conditional on the version, or
>>> via a file test would fix the problem, but it introduces some complexity
>>> to the build.
>>>
>>> Even without an explicit call to build version.h, it is always produced
>>> by the kernel build, so it can simply be removed.
>>>
>>> Note: it isn't clear why the explicit build of version.h was originally
>>> required, but the prep phases of the kernel have changed significantly,
>>> so it should no longer be required.
>>
>> I had a look through the archives. I think this is a throwback to 2.4,
>> we had to build the version.h file to figure out if we had a 2.6 or a
>> 2.4 kernel, then we could do the right thing to build it.
>>
>> Since we don't support 2.4 anymore, this can die!
>
> That makes my day.
>
> Should I resend, or is the RFC patch enough ?
>
Nope, It's merged into OE-Core

Thanks
	Sau!

> Bruce
>
>>
>> Cheers,
>>
>> Richard
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>