buildsystem: avoid if/then/else boiler plate when accessing hierarchy [RFC] #2432
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is something that's been bugging me for a while.
Currently we use this pattern which is repeated (with minor changes) in several places:
I think it would be better to use a helper function that takes care of locating the file or directory within the standard repo hierarchy (ie. project/device -> project -> distribution -> pkg etc.) so that the package doesn't have to care where the file is or might be, and packages can care less about projects, projects/devices, distros etc.
This change will eliminate almost all of this repeated code, while ensuring consistency whenever dealing with files and directories within the "standard repo hierarchy".
In terms of consistency, take this example in
buysbox
:The project-specific config file is not being searched for in
$PROJECT_DIR/$PROJECT/packages/busybox/config
which I would argue is a more appropriate location than$PROJECT_DIR/$PROJECT/busybox
.With this change we will use the same hierarchy in
$PROJECT_DIR
(and$PROJECT/devices/$DEVICE
and$DISTRO_DIR/$DISTRO
) that is used in$PKG_DIR
, which should help avoid confusion and errors.In the
busybox
case, the config file (if ever created) could be located in:which is analogous to the package directory location:
installer
is updated in a similar way tobusybox
.Another slight change is to
plymouth-lite
which now installs onlysplash-*.png
images - image using any other name are ignored. By changing the logic forplymouth-lite
it's also now possible to install a project specific config file, while continuing to use the standard distribution splash images.samba
will now installsamba.conf.sample
regardless of wheresmb.conf
is found (see comment).Some packages (eg.
xorg-server
,u-boot
,busybox
, etc.) were only searching in two or three locations (eg.$PROJECT
and$PKG_DIR
) but now they will be searching in all of the "standard" locations (including$DISTRO
), which may have unexepected consequences if a config file is ever added in a location that wasn't being searched prior to this change. I don't think this is a problem - it just means we need to be more careful/aware of where we put files.I've implemented the function in a slightly unusual way, in that it sets a global variable with the found path rather than echoing the found path (if no path is found the variable is left unset). This is to avoid using a temporary variable at the call site, or calling the function twice (once to determine if the path exists with
-n "$(find_file_path ...)"
, and then again to process the path - each time forking a new process).I've added optional logging whenever
find_path
is executed. I've made it optional as junk echoed while sourcing a package may be unexpected by some scripts, eg.repo-tool
. Enable logging withVERBOSE_FIND_PATH=yes
on the command line (or in$HOME/.libreelec/options
).