On Mon, 9 Dec 2024 at 17:33, Richard Purdie
<[email protected]> wrote:
> One thing which is still bugging me about this and causing some of my
> hesitation to merge things is the repeat of the name in the file path
> and in the flag name itself. This is going to be a pain to keep in sync
> over time.

I agree. It also simply visually clutters the fragment content without
need, fragments should be easy on the eye.

> b) Whether the fragment inclusion code should do a rename of any
> BB_CONF_FRAGMENT_SUMMARY -> BB_CONF_FRAGMENT_SUMMARY[<name>] during
> parsing. We could list the variables that need processing as parameters
> to the addfragments directive or in a variable.
>
> Of the two, I can see b) possibly working. We've never had a) work in a
> way that I've liked.

I was going to try this out, but I need to choose from two options.
The fragment path is given to parser like this:

                bb.parse.ConfHandler.include(self.filename,
fragment_path, self.lineno, data, "include fragment")

So fixing up the flags would either require passing in the list of
variables (that need fixing) into this call, which could turn out to
be an invasive change. Or we could parse everything as usual, and then
fix up the flags after the fact, e.g. just after this call. I'm
leaning towards the latter.

Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#208529): 
https://lists.openembedded.org/g/openembedded-core/message/208529
Mute This Topic: https://lists.openembedded.org/mt/109647318/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to