linux/poky.git/bitbake/lib/bb/parse, branch 5.2_M1

bitbake: bitbake: parse: add support for flagged fragment variables

2024-12-13T10:44:35+00:00

It was suggested that using flags in fragment content to mark fragment-specific metadata (such as descriptions and dependencies) is prone to quiet regressions when fragments are renamed or moved, and it clutters the fragment content. With this change allowed fragment metadata variables must be explicitly listed in a variable that is given to addfragment directive, and parser will add the flag containing the fragment name to them. (Bitbake rev: ed9a3ca9426500511feb77f41a146953dbfe9af7) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: parse: add support for 'addfragments' directive

2024-12-08T22:36:11+00:00

It takes two parameters: - location prefix for fragments - name of variable that holds the list of enabled fragments, each of them prefixed by layer id Implementation of this directive essentially expands the fragment list obtained from the variable into absolute fragment paths and hands them to the implementation of 'require'. (Bitbake rev: f687746703e7b096c5480668fd4f49bd4951182b) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: parse/ConfHandler: allow / in variable flags

2024-12-08T22:36:11+00:00

This is beneficial for config fragments, as their names are specified via flags, and those names can include slashes: BB_CONF_FRAGMENT_SUMMARY[init/systemd] = "This fragment enables systemd as an init manager" (Bitbake rev: 80805988492b35593067230f68782a5687c8f557) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: BBHandler/ast: Improve addtask handling

2024-08-13T14:47:55+00:00

The recent addtask improvement to handle comments complicated the regex significantly and there are already a number of corner cases in that code which aren't handled well. Instead of trying to complicate the regex further, switch to code logic instead. This means the following cases are now handled: * addtask with multiple task names * addtask with multiple before constraints * addtask with multiple after constraints The testcase is updated to match the improvements. (Bitbake rev: 417016b83c21fca7616b2ee768d5d08e1edd1e06) Signed-off-by: Richard Purdie

bitbake: BBHandler: Handle comments in addtask/deltask

2024-08-13T14:47:55+00:00

Technically our syntax would allow for comments after an addtask/deltask. Currently these get silently processed in various ways by the code which is bad. Tweak the regex to drop any comments and add test cases to ensure this continues to work in the future. [YOCTO #15250] (Bitbake rev: 64f8796e55a8826ffec0d76b993c8256713f67a3) Signed-off-by: Richard Purdie

bitbake: parse: Improve/fix cache invalidation via mtime

2024-05-16T22:25:55+00:00

We have been seeing obscure failures in devtool, particularly on newer autobuilder workers where it appears the cache is assumed to be valid when it shouldn't be. We're using the 'seconds' granulation mtime field which is not really a good way of telling if a file has changed. We can switch to the "ns" version which is better however also add in inode number and size as precautions. We already have all this data and tuples are fast so there isn't really any cost to do so. This hopefully fixes [YOCTO #15318]. (Bitbake rev: d9e5d313c79500e3c70ab9c3239b6b2180194f67) Signed-off-by: Richard Purdie

bitbake: BBHandler: Handle unclosed functions correctly

2024-04-14T05:31:45+00:00

A function accidentally defined as: somefunction() { : } which is unclosed due to the space at the end, would currently silently cause breakage. Have the parser throw and error for this. [YOCTO #15470] (Bitbake rev: a7dce72da6be626734486808f1b731247697e638) Signed-off-by: Richard Purdie

bitbake: ast/BBHandler: Add inherit_defer support

2024-01-18T10:15:58+00:00

Add support for an inherit_defer statement which works as inherit does but is only evaulated at the end of parsing. This allows conditional expressions to be evaulated 'late' meaning changes to PACKAGECONFIG from bbappends can be applied for example. This addresses a usability/confusion issue users have with the current conditional inherit mechanism since they don't realise the condition has to be expanded immediately with the current model. There is a commented out warning we could enable in future which warns about the use of a conditional inherit that isn't deferred. There is a behaviour difference in the placement of the inherit, particularly around variables set using ?= which means wen swapping from one to the other, caution must be used as values can change. (Bitbake rev: 5c2e840eafeba1f0f754c226b87bfb674f7bea29) Signed-off-by: Richard Purdie

bitbake: ast: Fix EXPORT_FUNCTIONS bug

2024-01-10T13:55:33+00:00

If you have two classes, both of which set EXPORT_FUNCTIONS for the same funciton and a standard funciton definition for the function that is exported, the export function can sometimes overwrite the standard one. The issue is that the internal flag the code uses isn't ovweritten if the variable is giving a new value. Fix the issue by using a comment in the code that is injected so that we know if it is ours or not. Also add some testing for EXPORT_FUNCTIONS, not perfect but a start. (Bitbake rev: 66306d5151acb0a26a171c338d8f60eb9eb16c6b) Signed-off-by: Richard Purdie

bitbake: lib: Drop inotify support and replace with mtime checks

2023-09-18T10:35:05+00:00

With the flush in serverlog() removed and a memory resident bitbake with a 60s timeout, the following could fail in strange ways: rm bitbake-cookerdaemon.log bitbake-layers add-layer ../meta-virtualization/ bitbake-layers add-layer ../meta-openembedded/meta-oe/ bitbake -m specifically that it might error adding meta-oe with an error related to meta-virt. This clearly shows that whilst bblayers.conf was modified, bitbake was not recognising that. This would fit with the random autobuilder issues seen when the serverlog flush() call was removed. The issue appears to be that you have no way to "sync()" the inotify events with the command stream coming over the socket. There is no way to know if there are changes in the IO queue which bitbake needs to wait for before proceeding with the next command. I did experiment with os.sync() and fsync on the inotify fd, however nothing addressed the issue. Since it is extremely important we have accurate cache data, the only realistic thing to do is to switch to stat() calls and check mtime. For bitbake commands, this is straightforward since we can revalidate the cache upon new connections/commands. For tinfoil this is problematic and we need to introduce and explict command "revalidateCaches" that the code can use to force bitbake to re-check it's cache validity. I've exposed this through tinfoil with a new "modified_files" function. So, this patch: a) drops inotify support within bitbake's cooker/server and switch to using mtime b) requires a new function call in tinfoil when metadata has been modified (Bitbake rev: da3ec3801bdb80180b3f1ac24edb27a698415ff7) Signed-off-by: Richard Purdie