On Mon, Oct 8, 2018 at 5:18 AM Urs Fässler <urs.fass...@bbv.ch> wrote: > > On Tue, 2018-10-02 at 10:44 -0400, bruce.ashfielda wrote: > > On 2018-10-01 8:42 AM, Urs F?ssler wrote: > > > Recommend to add recipe-space features to SRC_URI so that changes > > > to them > > > are detected automatically. > > > > > > Signed-off-by: Urs F?ssler <urs.fassler at bbv.ch> > > > Signed-off-by: Pascal Bach <pascal.bach at siemens.com> > > > --- > > > documentation/kernel-dev/kernel-dev-common.xml | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/documentation/kernel-dev/kernel-dev-common.xml > > > b/documentation/kernel-dev/kernel-dev-common.xml > > > index 83b02b1c1..6289ce8d4 100644 > > > --- a/documentation/kernel-dev/kernel-dev-common.xml > > > +++ b/documentation/kernel-dev/kernel-dev-common.xml > > > @@ -2623,6 +2623,9 @@ > > > <filename>.scc</filename> file in the > > > <filename>SRC_URI</filename> statement to reference > > > multiple kernel > > > features. > > > + Since BitBake only detects changes on files listed in > > > + <filename>SRC_URI</filename>, it is best to add all > > > > This is not necessarily true. It would be better stated that if you > > are modifying the .cfg files in the layer directly, you should list > > them on the SRC_URI to have the changes picked up by bitbake. > > > > It is not a matter of "best", so it should be stated that way. > > Thank you for the feedback. I am not sure if I don't understand the > problem or your answer correctly.
I meant to say "not stated that way". > > We faced the problem, that our CI server did not picked up the changes > made in the .cfg files. I investigated the problem and found that > BitBake only detects changes on files listed in SRC_URI. This is > supported in the chapter "Working with Advanced Metadata" that states: I'm aware of how the items are currently written, having provided much of the information for those sections. > > "BitBake parses [the .scc files] and fetches any files referenced in > the .scc files by the include, patch, or kconf commands. Because of > this, it is necessary to bump the recipe PR value when changing the > content of files not explicitly listed in the SRC_URI." > https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#recipe-space-metadata > > The behavior is imho not what you expect. But fixing this is quite a > big change since it involves changes in the interaction of BitBake > (change detection on files) with Yocto classes (recursive parsing of > scc files). Therefore I try to solve it with a better description. Yep. I've had a bug/feature to do just that for some time, but it hasn't made it to the top of the list yet. My point is that the description should not say "best", it isn't a matter of best or worst. It is a matter of stating the behaviour, knowing how you plan to interact with the elements and then using them appropriately. > > You stated that it is only necessary to add the .cfg files when you > change the .cfg files in the layer directly. I don't see how you would > change the .cfg files otherwise or what use case you have in mind. By using a kernel-cache repository. Just like all the main linux-yocto builds. Alternatively, you could make sure the gather meta-data task is always run, but then that typically triggers more compiles/builds than you want. > > > > @+ <filename>.cfg</filename> to > > > <filename>SRC_URI</filename>. > > > </para> > > > > > > <para> > > > @@ -2674,10 +2677,10 @@ > > > </para></listitem> > > > <listitem><para> > > > <emphasis>Add the Feature File to > > > <filename>SRC_URI</filename>:</emphasis> > > > - Add the <filename>.scc</filename> file to the > > > + Add the <filename>.cfg</filename> and > > > <filename>.scc</filename> file to the > > > recipe's <filename>SRC_URI</filename> > > > statement: > > > <literallayout class='monospaced'> > > > - SRC_URI_append = " file://test.scc" > > > + SRC_URI_append = " file://test.cfg file://test.scc" > > > > This is wrong. You should not have both on the SRC_URI > > I concluded this also from the description in the "Working with > Advanced Metadata" chapter (see above). But I would be happy to know > about another solution for our problem. If all that test.scc does is include test.cfg, you don't put both on the SRC_URI. All you've done is include it twice. If you are worried about modifying the .cfg's and having sstate be invalided so the tasks re-run, then you'd just put the .cfg on the SRC_URI. Bruce > > Urs > > > > </literallayout> > > > The leading space before the path is > > > important as the > > > path is appended to the existing path. > > > > -- > _______________________________________________ > 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" -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core