merge it with git_prep, since it's only a small
function and only called from there. the merged
code still makes sense and its purpose is still
quite clear on casual reading.
Signed-off-by: Leah Rowe <leah@libreboot.org>
merge it with git_prep, since it's only a tiny
function and only called from there. the for
loop moved to the if block still makes sense
on casual reading.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the "u" argument can actually be any thing. git_prep
handles git submodules only for single-tree projects,
under any candition, or on multi-tree projects if
the number of arguments to git_prep is above four.
"u" is the 5th argument, meant to enable submodule
downloads. it really doesn't matter what this string
says, so let's just make it as clear as possible.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the combination of x_ with the "e" function enables
for much simpler file-check error handling, which is
a unique innovation of lbmk as it pertains to sh.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the cbfs function will call cbfstool, which will perform
the same check, and the same error condition would cause
the same exit behaviour in lbmk. the error message would
also provide output that is just as useful for debugging.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There was no error handling, *at all*, on the actual tar
command, due to the lack of set -o pipefail, which we cannot
rely on in sh.
The x_ wrapper can be used in this case, as a mitigation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it wouldn't exit with error status anyway, since i'm
setting +e here, but if that accidentally changed in
the future, i still wouldn't want this to exit.
the bruteforce me extraction naturally throws a lot of
errors, hence +e, because of how the extraction works,
but the result is checked at the end of the process,
to compensate. hence +e, because otherwise this brute
force extraction would never work.
therefore, this is an extremely theoretical bug fix, the
most quintessential of preemptive bug fixes, to the point
that it is actually rather pedantic.
The ":" in "|| :" will likely *never* be executed, but it
handles the theoretical case where the subshell exits with
non-zero status and +e is set; subshells aren't meant to
behave this way anyway, but who knows what cursed sh
implementation the user is on?
Signed-off-by: Leah Rowe <leah@libreboot.org>
in these if clauses, what follows afterward is exactly
the same: set xchanged and return.
Therefore, these lines are redundant and they can be
removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This change finally ensures that no insertions will be
attempted, on the basis that readkconfig failed; this
covers the instance whereby vcfg was set, but no scanned
items were indicated e.g. Intel ME files not specified.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This should speed up automated tests. Otherwise, it goes
through all the extra checks that aren't needed, for each
individual type of vendor file, and also errors out when
handling pico serprog images; during automated testing,
on the bin directory, you might try on every tarball, one
of which is the pico tarball and this patch makes lbmk skip
that one too.
In general, we must not perform unnecessary tasks. Doing so
may even cause other bugs that we couldn't easily detect.
Signed-off-by: Leah Rowe <leah@libreboot.org>
x_ cannot be used, where output is redirectod to a file;
only the conventional piping can be used.
same as the last change. this and the other fix were caught
during testing.
Signed-off-by: Leah Rowe <leah@libreboot.org>
x_ cannot be used, where output is redirected to a file;
only the convention piping can be used, for errors.
relying on x_ in these cases will cause unpredictable bugs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i can't call $err (variable), because it's set
to fail_inject. fix this infinite loop, which
was an oversight in the previous commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I was using a complicated method of knowing whether
the current instance was parent or a child, to know
whether the lock file and TMPDIR needed to be purged.
It was quite error-prone too. Instead, I'm now handling
it directly from within the if statement that previously
initialised xbmk_parent=y, forking ./mk from there.
The forked instance would not trigger that if clause
again, since then TMPDIR is created, thus avoiding
recursion.
This is an improvement because it doesn't rely on how
the parent handles exit statuses, and it ensures that
the lock/tmp files are never accidentally deleted.
Even if a given program/script that lbmk runs would
export TMPDIR, it doesn't matter because lbmk doesn't,
so it would be unaffected.
Signed-off-by: Leah Rowe <leah@libreboot.org>
because the top-down function order isn't as reliable
in lib.sh, since this is what first runs, included
in every other script
Signed-off-by: Leah Rowe <leah@libreboot.org>
write to .version and .versiondate, instead
of version and versiondate.
this will hide them to avoid visual clutter while
analysing files within lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of running pwd all the time, run it once in lib.sh,
and export PWD.
for lbmk-specific use of PWD, use xbmkpwd, which contains
the value of PWD as was set by the pwd utility in lib.sh.
many parts of lbmk rely on pwd, and it *must* be correct.
this change adds basic error handling, since pwd can in
fact return errors in some cases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's incorrect for PATH not to be set, but some users
may foolishly blank it out before running lbmk.
prevent such issues, by initialising it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
PWD could be anything, if the user manually exported
it before running lbmk.
always run pwd instead, to get the real string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
several code lines were condensed together, which
make them less readable. make the code more readable
by having separate commands on separate lines.
i previously did this during my manic build system
audits of 2023 and 2024; condensing lines like this
is overly pedantic and serves no real purpose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe