On Wed, 2025-02-12 at 12:45 -0500, Bruce Ashfield wrote: > On Wed, Feb 12, 2025 at 12:24 PM Stefan Herbrechtsmeier > <stefan.herbrechtsmeier-...@weidmueller.com> wrote: > > > > > > > > > > > > > > As a compromise we could add a new feature to generate .inc > > > > cache files before the main bitbake run. This would eliminate > > > > the manual update run and the commit noise as well as special > > > > fetch, unpack and patch task. > > > > > > > Can you elaborate on what you mean by before the main bitbake run > > > ? Would it be still under a single bitbake invokation or would it > > > be multiple runs (I support multiple runs, so don't take that as > > > a leading question). > > > > > I can't answer this questions and need Richard guidance to > > implement such a feature. I would assume that bitbake already track > > file changes and can update its state. The behavior should be > > similar to a change in the .inc file. Bitbake will detect that a > > "include_cache" file is missing and run an update_cache task on the > > recipe. Afterwards bitbake detect a file change on the > > "include_cache" file and parse it. We need a possibility to mark > > patches which shouldn't be applied if the "include_cache" file is > > missing because the dependencies are missing. We need to run the > > fetch, unpack and patch task before the update_cache task to > > generate the .inc file. > > > Aha. Maybe Richard will comment later. I was thinking more about > something that was in two distinct phases, but with some more > thinking and explanation, maybe this is workable as well.
We don't have anything in bitbake which could support this currently. We parse once, store a subset of the data and then have all the information bitbake needs. There is no second parse something else later in the task graph concept or support, or support for "generate this file if missing", particularly if generating that file would require other tasks to run. That said, I am wondering if we need to do something differently here, it is obviously just going to complicate things a lot if we need new concepts and API at that level in bitbake. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211269): https://lists.openembedded.org/g/openembedded-core/message/211269 Mute This Topic: https://lists.openembedded.org/mt/111123548/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
