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.
But I'm not really sure I like globs at all in filename directives, 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 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?)
--Mark
MarkA
MarkA
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2072):
https://lists.openembedded.org/g/openembedded-architecture/message/2072
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]]
-=-=-=-=-=-=-=-=-=-=-=-
