Q: Kernel SCC files: shouldn't a changed patch trigger a rebuild?

Q: Kernel SCC files: shouldn't a changed patch trigger a rebuild?

[Erwin Rieger]

Hello list,

i have written a kernel recipe derived from linux-yocto-custom. The
SRC_URI includes a SCC file that in turn includes a kernel patch.

First of all, this works as expected, the patch is applied to the kernel
source and my custom kernel is built.

But the kernel is NOT rebuilt if i modify the kernel patch (without
touching the SCC file). In other words: changed files that are directly
named in the SRC_URI variable trigger a rebuild, but indirectly included
changed input files (through a SCC file) do not.

Is this the intended behaviour?


PS: 
I can provide more info and my test files if needed.






-- 
Mit freundlichen Gruessen Erwin Rieger

--------------------------------------------------------------------
| Ingenieurbuero Rieger, Software Entwicklung
| EMail: erwin.rieger@ibrieger.de
--------------------------------------------------------------------

Re: Q: Kernel SCC files: shouldn't a changed patch trigger a rebuild?

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Wed, Dec 6, 2017 at 6:46 PM, Erwin Rieger <erwin.rieger@ibrieger.de>
wrote:

>
> Hello list,
>
> i have written a kernel recipe derived from linux-yocto-custom. The
> SRC_URI includes a SCC file that in turn includes a kernel patch.
>
> First of all, this works as expected, the patch is applied to the kernel
> source and my custom kernel is built.
>
> But the kernel is NOT rebuilt if i modify the kernel patch (without
> touching the SCC file). In other words: changed files that are directly
> named in the SRC_URI variable trigger a rebuild, but indirectly included
> changed input files (through a SCC file) do not.
>
> Is this the intended behaviour?
>


Currently that is the intended behaviour.

The fetcher is what is responsible for detecting if something changes, and
re-fetching, etc.
The fetcher only knows about the files on the SRC_URI (or the SRCREV for a
remote repository).

The patch referenced by the .scc file is not directly on the SRC_URI so it
doesn't trigger
the re-fetch.

I've had an old bugzilla for this for some time, and have tried on a couple
of occasions to
address it, but ended up not getting the semantics right. i.e. not
re-inventing the fetcher
or duplicating code, etc.

I manage all my patches via either .scc files on the SRC_URI or via a repo
containing
.scc files + patches. Since that allows me to re-use them as functional
blocks between
kernels and couples changes to their configuration fragments. (I only point
that out to
say that your use case and workflow is valid)

If you do store the .scc files + patches in a repo, and fetch it via
AUTOREV (or a set SRCREV),
then you will get the behaviour you are looking for.

I'll bubble this back up to the top of my queue and follow up when I know a
bit more. I need
to revisit my old notes and see if anything is viable.

Cheers,

Bruce


>
>
> PS:
> I can provide more info and my test files if needed.
>
>
>
>
>
>
> --
> Mit freundlichen Gruessen Erwin Rieger
>
> --------------------------------------------------------------------
> | Ingenieurbuero Rieger, Software Entwicklung
> | EMail: erwin.rieger@ibrieger.de
> --------------------------------------------------------------------
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



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

[-- Attachment #2: Type: text/html, Size: 3787 bytes --]