[PATCH 1/3] base.bbclass: Avoid explicit ${MAKE} in do_configure

[PATCH 1/3] base.bbclass: Avoid explicit ${MAKE} in do_configure

[Otavio Salvador]

The do_configure may eventually call 'make clean' when the sstate
signature does not match. We should respect EXTRA_OEMAKE when doing
so, so use 'oe_runmake' for it.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index b8f61f3..de50be1 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -227,7 +227,7 @@ base_do_configure() {
 		if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
 			cd ${B}
 			if [ "${CLEANBROKEN}" != "1" -a \( -e Makefile -o -e makefile -o -e GNUmakefile \) ]; then
-				${MAKE} clean
+				oe_runmake clean
 			fi
 			find ${B} -name \*.la -delete
 		fi
-- 
2.1.4

[PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE

[Otavio Salvador]

When the sstate hash changes for do_configure task, the do_configure
default implementation triggers the 'clean' to be run. For it to
succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
following error:

,----
| DEBUG: Executing shell function do_configure
| NOTE: make -e MAKEFLAGS= clean
| make -C  M=.../tmp/work/... clean
| make[1]: *** M=.../tmp/work/...: No such file or directory.  Stop.
| Makefile:20: recipe for target 'clean' failed
| make: *** [clean] Error 2
| ERROR: oe_runmake failed
`----

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/classes/module.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index ad6f7af..5cb8623 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
 do_make_scripts[deptask] = "do_populate_sysroot"
 
+EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
+
 module_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
-		   KERNEL_SRC=${STAGING_KERNEL_DIR}    \
 		   KERNEL_VERSION=${KERNEL_VERSION}    \
 		   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 		   AR="${KERNEL_AR}" \
@@ -19,7 +20,6 @@ module_do_compile() {
 module_do_install() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
-	           KERNEL_SRC=${STAGING_KERNEL_DIR} \
 	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 	           modules_install
 }
-- 
2.1.4

Re: [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE

[Bruce Ashfield]

On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> When the sstate hash changes for do_configure task, the do_configure
> default implementation triggers the 'clean' to be run. For it to
> succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
> following error:

I wanted to reproduce this locally, since I've never seen the problem
myself.

What's the best way to trigger the sstate hash change ?

I also have a question below ...

>
> ,----
> | DEBUG: Executing shell function do_configure
> | NOTE: make -e MAKEFLAGS= clean
> | make -C  M=.../tmp/work/... clean
> | make[1]: *** M=.../tmp/work/...: No such file or directory.  Stop.
> | Makefile:20: recipe for target 'clean' failed
> | make: *** [clean] Error 2
> | ERROR: oe_runmake failed
> `----
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  meta/classes/module.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index ad6f7af..5cb8623 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
>  do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
>  do_make_scripts[deptask] = "do_populate_sysroot"
>
> +EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
> +

I'm not seeing very well at the moment and my ability to browse the code
is restricted, so bear with a potentially stupid question.

It's clear from the error message above why this is needed, but I'm not
seeing the code that is respecting/using KERNEL_SRC to trigger the
clean in the right directory. Where exactly is this being used (I know your
related base.bbclass change will pull in the extra make args, but I'm just
not seeing the Makefile that respects it).

Basically, I'm trying to decide if it would be better to handle this all in
the module class, and add a do_configure to the do_compile and
do_install we already have.

Since I'm not seeing it, others might not as well .. and we can enhance the
comments to make it clear.

Bruce

>  module_do_compile() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
> -                  KERNEL_SRC=${STAGING_KERNEL_DIR}    \
>                    KERNEL_VERSION=${KERNEL_VERSION}    \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    AR="${KERNEL_AR}" \
> @@ -19,7 +20,6 @@ module_do_compile() {
>  module_do_install() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
> -                  KERNEL_SRC=${STAGING_KERNEL_DIR} \
>                    CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>                    modules_install
>  }
> --
> 2.1.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE

[Otavio Salvador]

On Wed, Jan 7, 2015 at 4:45 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> When the sstate hash changes for do_configure task, the do_configure
>> default implementation triggers the 'clean' to be run. For it to
>> succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
>> following error:
>
> I wanted to reproduce this locally, since I've never seen the problem
> myself.
>
> What's the best way to trigger the sstate hash change ?
>
> I also have a question below ...

This was triggered when I did a change in the kernel-module-mcc; so
when I changed the recipe it triggered the configure.

>> ,----
>> | DEBUG: Executing shell function do_configure
>> | NOTE: make -e MAKEFLAGS= clean
>> | make -C  M=.../tmp/work/... clean
>> | make[1]: *** M=.../tmp/work/...: No such file or directory.  Stop.
>> | Makefile:20: recipe for target 'clean' failed
>> | make: *** [clean] Error 2
>> | ERROR: oe_runmake failed
>> `----
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>>  meta/classes/module.bbclass | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
>> index ad6f7af..5cb8623 100644
>> --- a/meta/classes/module.bbclass
>> +++ b/meta/classes/module.bbclass
>> @@ -6,10 +6,11 @@ addtask make_scripts after do_patch before do_compile
>>  do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
>>  do_make_scripts[deptask] = "do_populate_sysroot"
>>
>> +EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
>> +
>
> I'm not seeing very well at the moment and my ability to browse the code
> is restricted, so bear with a potentially stupid question.

No worries.

> It's clear from the error message above why this is needed, but I'm not
> seeing the code that is respecting/using KERNEL_SRC to trigger the
> clean in the right directory. Where exactly is this being used (I know your
> related base.bbclass change will pull in the extra make args, but I'm just
> not seeing the Makefile that respects it).
>
> Basically, I'm trying to decide if it would be better to handle this all in
> the module class, and add a do_configure to the do_compile and
> do_install we already have.
>
> Since I'm not seeing it, others might not as well .. and we can enhance the
> comments to make it clear.

It was triggered from the module Makefile. So it basically runned:

make clean

and it tried to load it from kernel source, which obviously failed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 2/3] module.bbclass: Add KERNEL_SRC in EXTRA_OEMAKE

[Richard Purdie]

On Wed, 2015-01-07 at 13:45 -0500, Bruce Ashfield wrote:
> On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
> > When the sstate hash changes for do_configure task, the do_configure
> > default implementation triggers the 'clean' to be run. For it to
> > succeed we need to have KERNEL_SRC defined in EXTRA_OEMAKE. Fixes
> > following error:
> 
> I wanted to reproduce this locally, since I've never seen the problem
> myself.
> 
> What's the best way to trigger the sstate hash change ?

bitbake virtual/kernel -c configure -f

Cheers,

Richard

[PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it

[Otavio Salvador]

Old Linux kernel versions rely on linux/version.h for modules; this
needs to be published for external modules to use. Copy it when
available.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/classes/kernel.bbclass | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 88356b1..78c8c7c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -252,6 +252,10 @@ kernel_do_install() {
 	cp .config $kerneldir/
 	mkdir -p $kerneldir/include/config
 	cp include/config/kernel.release $kerneldir/include/config/kernel.release
+	if [ -e include/linux/version.h ]; then
+		mkdir -p $kerneldir/include/linux
+		cp include/linux/version.h $kerneldir/include/linux/version.h
+	fi
 
 	# As of Linux kernel version 3.0.1, the clean target removes
 	# arch/powerpc/lib/crtsavres.o which is present in
-- 
2.1.4

Re: [PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it

[Bruce Ashfield]

Unless anyone needs these really fast, I'll queue the two kernel
patches and take them
for a spin today.

I have a variant of the version.h here (and when the directories
shuffle again, we can drop
explicit copies all together), but will make the switch for this in
the short term.

Bruce

On Wed, Jan 7, 2015 at 12:25 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Old Linux kernel versions rely on linux/version.h for modules; this
> needs to be published for external modules to use. Copy it when
> available.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  meta/classes/kernel.bbclass | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 88356b1..78c8c7c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -252,6 +252,10 @@ kernel_do_install() {
>         cp .config $kerneldir/
>         mkdir -p $kerneldir/include/config
>         cp include/config/kernel.release $kerneldir/include/config/kernel.release
> +       if [ -e include/linux/version.h ]; then
> +               mkdir -p $kerneldir/include/linux
> +               cp include/linux/version.h $kerneldir/include/linux/version.h
> +       fi
>
>         # As of Linux kernel version 3.0.1, the clean target removes
>         # arch/powerpc/lib/crtsavres.o which is present in
> --
> 2.1.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 3/3] kernel.bbclass: When linux/version.h exists, copy it

[Otavio Salvador]

On Wed, Jan 7, 2015 at 3:47 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> Unless anyone needs these really fast, I'll queue the two kernel
> patches and take them
> for a spin today.
>
> I have a variant of the version.h here (and when the directories
> shuffle again, we can drop
> explicit copies all together), but will make the switch for this in
> the short term.

We have failures due this in meta-fsl-arm; it is for master only so we
can live with failures for some days.

I am happy you have something in same line.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750