* [RFC PATCH 0/1] kernel.bbclass: remove explicit version.h target
@ 2012-10-18 14:47 Bruce Ashfield
2012-10-18 14:47 ` [PATCH 1/1] " Bruce Ashfield
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Ashfield @ 2012-10-18 14:47 UTC (permalink / raw)
To: richard.purdie; +Cc: dvhart, openembedded-core
Hi all,
I'm doing a quick RFC on a patch to get 3.7 based kernels building
again.
The patch has the details on the kernel commits that have moved
version.h around, which breaks our builds due to an explicit reference
in kernel.bbclass.
I thought about making the call conditional, but as the patch says,
this introduces a bit more complexity where it might not be
required. Removing the reference to version.h fixes the build, and
didn't break any of my older kernel builds (2.6.39, 3.0, 3.2, 3.4)
while still producing version.h.
I can't locate the original reason that version.h was being directly
built, so that's why this is a RFC. I'm hoping someone will yell if
this breaks a use case that I don't know about.
This is stacked on top of my yocto master branch, since it was a
RFC. I can rebase onto oe-core, or master under test as appropriate.
Cheers,
Bruce
The following changes since commit e6e2b9bd66100c078c029ca7e34829cf1dfb5490:
documentation: poky-ref-manual - edits to MACHINE type variables. (2012-10-18 12:15:04 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
Bruce Ashfield (1):
kernel.bbclass: remove explicit version.h target
meta/classes/kernel.bbclass | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
--
1.7.5.4
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/1] kernel.bbclass: remove explicit version.h target
2012-10-18 14:47 [RFC PATCH 0/1] kernel.bbclass: remove explicit version.h target Bruce Ashfield
@ 2012-10-18 14:47 ` Bruce Ashfield
2012-10-18 14:53 ` Darren Hart
2012-10-18 15:12 ` Richard Purdie
0 siblings, 2 replies; 6+ messages in thread
From: Bruce Ashfield @ 2012-10-18 14:47 UTC (permalink / raw)
To: richard.purdie; +Cc: dvhart, openembedded-core
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(-)
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}"
--
1.7.5.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 1/1] kernel.bbclass: remove explicit version.h target
2012-10-18 14:47 ` [PATCH 1/1] " Bruce Ashfield
@ 2012-10-18 14:53 ` Darren Hart
2012-10-18 15:12 ` Richard Purdie
1 sibling, 0 replies; 6+ messages in thread
From: Darren Hart @ 2012-10-18 14:53 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: openembedded-core
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}"
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/1] kernel.bbclass: remove explicit version.h target
2012-10-18 14:47 ` [PATCH 1/1] " Bruce Ashfield
2012-10-18 14:53 ` Darren Hart
@ 2012-10-18 15:12 ` Richard Purdie
2012-10-18 16:35 ` Bruce Ashfield
1 sibling, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2012-10-18 15:12 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: dvhart, openembedded-core
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] kernel.bbclass: remove explicit version.h target
2012-10-18 15:12 ` Richard Purdie
@ 2012-10-18 16:35 ` Bruce Ashfield
2012-10-19 21:24 ` Saul Wold
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Ashfield @ 2012-10-18 16:35 UTC (permalink / raw)
To: Richard Purdie; +Cc: dvhart, openembedded-core
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] kernel.bbclass: remove explicit version.h target
2012-10-18 16:35 ` Bruce Ashfield
@ 2012-10-19 21:24 ` Saul Wold
0 siblings, 0 replies; 6+ messages in thread
From: Saul Wold @ 2012-10-19 21:24 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: dvhart, openembedded-core
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-19 21:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-18 14:47 [RFC PATCH 0/1] kernel.bbclass: remove explicit version.h target Bruce Ashfield
2012-10-18 14:47 ` [PATCH 1/1] " Bruce Ashfield
2012-10-18 14:53 ` Darren Hart
2012-10-18 15:12 ` Richard Purdie
2012-10-18 16:35 ` Bruce Ashfield
2012-10-19 21:24 ` Saul Wold
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox