a very weird question, to be sure, but i literally just ran across a recipe that does the following (i will paraphrase some stuff to protect the innocent).
the recipe processes a bunch of XML source files, and generates from them JSON files, so any change in any of the XML source files should (obviously) trigger a rebuild of the recipe. and here's the problem. the XML files are not copied into the recipe source directory, and are not even referenced by SRC_URI. rather, the files live in a well-known location on the build host (placed there by a monstrous "repo sync"), and to save time and space, the recipe just *symlinks* from inside ${S} to the XML source files outside of ${S}, then proceeds to process them to generate the subsequent JSON files. the complaint is that, when the build pipeline started taking advantage of sstate-cache, even after some of the XML files were changed, the recipe would not rebuild. once i understood what was happening, my immediate reaction was along the lines, "well, since what is under ${S} is simply symlinks to files *outside* of ${S} and (worse) those symlink names will never change (all that will change is the XML files at the other end), how is bitbake supposed to have any idea that those XML files have changed to kick off a rebuild?" so my initial response was, "this does not surprise me at all," but does my reasoning hold up? obviously, this should probably use a combination of bin_package and externalsrc, but as it is now, is it moderately accurate to suggest that it is those symlinks that are preventing bitbake from understanding that anything has changed, so that it continues to use the old sstate-cache? rday
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193864): https://lists.openembedded.org/g/openembedded-core/message/193864 Mute This Topic: https://lists.openembedded.org/mt/103762271/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-