[yocto] Incremental rebuild doesn't pick up FILES changes.

[Kaz Kylheku (poky)]

On 2019-03-06 10:23, Richard Purdie wrote:
> On Tue, 2019-03-05 at 18:28 -0800, Kaz Kylheku (poky) wrote:
>> How do we get Yocto to react to FILES changes, short of blowing away
>> the entire build tree?
> 
> Maybe related to this change:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa

Actually, the problem was that I had an accidental local change applied
to the .json manifest file; that's where the 
"${libdir}/python2.7/encodings" was
being deleted.

So, the issues are now is that

FILES_${PN}_remove = "${libdir}/python2.7/encodings"

in fact does not work, as I believed.  It doesn't register at all. If I 
run "bitbake -e", to find the places that influence the value of $FILES, 
this _remove assignment doesn't appear anywhere. In fact, the name of my 
.bbpappend file doesn't even appear anywhere in that listing.

If I change it to just FILES_remove = ...  then it does show up in 
"bitbake -e" (early, before all the base recipe manipulations of 
$FILES). It doesn't work; the encodings do not disappear:


      $FILES [527 operations]
     #   set /mnt/sdb4/kaz/proj/poky/meta/conf/bitbake.conf:288
     #     ""
     #   set /mnt/sdb4/kaz/proj/poky/meta/conf/documentation.conf:169
     #     [doc] "The list of directories or files that are placed in 
packages."
     #   _remove 
/mnt/sdb4/kaz/proj/meta-custom/common/recipes-devtools/python/python_%.bbappend:15
     #     "${libdir}/python2.7/encodings"

     [ big snip ]

     #   override[python-core]:append python_2.7.15.bb:220 
[__anon_238__mnt_sdb4_kaz_y25_wp76_poky_meta_recipes_devtools_python_python_2_7_15_bb]
     #     " ${libdir}/python2.7/encodings"

I think this override might be winning over the _remove or something. 
The output never shows the final, settled value of FILES. At the bottom 
of this section about the $FILES variable we just have:

     # pre-expansion value:
     #   ""
     FILES=""

which is uninformative; obviously there is a populated FILES because the 
package has files in it.

Should I just add some install append steps to "rm -f" the unwanted 
material and be done with it?

I feel there should be a sane way to customize the FILES variable (and 
any other) emanating from a base recipe, though.