On 11/12/2024 1:13 PM, Mark Hatle wrote:
>
>
> On 11/12/24 12:05 PM, Mark Asselstine via lists.openembedded.org wrote:
>>
>>
>> On 11/12/2024 12:58 PM, Mark Hatle wrote:
>>>
>>>
>>> On 11/6/24 2:12 PM, Mark Asselstine via lists.openembedded.org wrote:
>>>>
>>>>
>>>> On 11/6/2024 9:18 AM, Richard Purdie via lists.openembedded.org wrote:
>>>>> I think we've had this idea around on occasions before but I'm
>>>>> going to
>>>>> write it down as an official proposal. In the interests of small
>>>>> contained but useful tweaks, I'd like to suggest we add an
>>>>> "include_all" directive.
>>>>>
>>>>> Example usage would be:
>>>>>
>>>>> include_all conf/distro/include/maintainers.inc
>>>>>
>>>>> which would iterate BBPATH and include (in order) each maintainers.inc
>>>>> file it finds.
>>>>>
>>>>> This would be used for things like the maintainers inc files so that
>>>>> other layers could add values to some central list. The clang inc
>>>>> files
>>>>> were another possible use case or the static libs or other inc
>>>>> files we
>>>>> have in core.
>>>>>
>>>>> It would all a few more files bitbake would have to check for the
>>>>> presence of to check cache validation but that is already a complex
>>>>> problem and we have ways to handle this.
>>>>>
>>>>> I did wonder about "require_all" but I doubt we need the difference in
>>>>> semantics for this form of operation and include is good enough.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Would it make sense to continue to use 'include' and make use of some
>>>> form of globbing on the path to make it convey that there are going to
>>>> be additional matches?
>>>
>>> I prefer include_all because it's explicit in what it's going to do.
>>> While an include <path>/<glob> as a reader you need to understand this
>>> does, and I don't think its obvious at all.
>>
>> That is sort of like saying "ls /etc/*" is harder to understand than
>> "ls_all /etc/". I find it harder to recall an expanding list of
>> directives than a pattern used throughout Linux. At any rate, point
>> taken, I hear you.
>
> include_all conf/maintainers.inc
>
> vs
>
> include conf/maintainers*
>
> The first one though would go through ALL of the search paths and
> include all of the files with a specific path/name.
>
> If the second even works, I would expect it to include the first
> maintainers file it found, not all of them.. but even if it did more
> then once, it would be from the first search path and stop.
Again, using the globbing as you would for ls or rm there would be no
expectation to stop at the first one. It would follow an established
pattern found elsewhere in Linux commands.
>
> But I'm not really sure I like globs at all in filename directives,
BTW, it could prove useful for paths as well 'include */maintainers.inc'
> since they can end up doing 'surprising' things that are not obvious to
> many users. At least with the current syntax of:
>
> include ${MY_LIST}
>
> someone could generate a list of multiple items and they would all be
> included, but that is easier to 'diagnose' using bitbake -e and viewing
I think bitbake -e could similarly be used to diagnose issues. Since we
are using the same pattern as ls the globbing can be diagnosed by
knowing the location the include is being 'run' in.
> the contents of MY_LIST. How would we view the contents of the 'glob'
> in an:
>
> include conf/maintainers*
>
> (or worse, how do you 'glob' that I just want conf/maintainers.inc?)
That is a good point as without any globbing it will only find the one
and not all in BBPATH. A leading "*" could denote this possibly.
I am not fuss on this, I think globbing opens the door to other
possibilities and avoids a new directive. I can concede that it is also
not a perfect approach but appreciate the discussion.
MarkA
>
> --Mark
>
>> MarkA
>>
>>>
>>>> MarkA
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2073):
https://lists.openembedded.org/g/openembedded-architecture/message/2073
Mute This Topic: https://lists.openembedded.org/mt/109425270/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
