the git_prep function already creates the given
directory where source code goes, so we don't
need to do it from the trees script.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when downloading multi-tree projects, the rev can be reset
to HEAD instead of the actual rev for a given target. this
occurs when the bare repo (e.g. src/coreboot/coreboot) does
not exist and has to be downloaded first.
bare repository downloading does not rely on target.cfg, in
this context, only pkg.cfg, but it uses the same variable
names (e.g. "rev").
instead of using a separate variable name, thus increasing
code complexity (which is the exact opposite of what i want
to do), do the bare repository download first.
this means that the git.sh script is much cleaner now, for
multi-tree projects, in that it *only* copies the bare repo
then runs git_prep; in that context, the bare repo is cloned
directly by calling the relevant function from script/trees,
which is the same behaviour as when cloning single-tree
project sources.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the same function that loads configurations for single-tree
projects has been merged with the function for multi-tree
configs in git.sh, and that functionality has been removed
from git.sh; now it is all unified in the trees script.
as the saying goes: write one program to do one thing well.
the purpose of git.sh is to download source code, but not
to handle configuration files; the latter is meant to be
handled by the trees script, which then calls into git.sh
before running the build logic for that given project.
additionally: the "seen" files are no longer handled, at all.
the logic there was added ages ago, because at the time, i was
considering whether to separate configuration into a new
repository, so that users could more easily make their own
configuration, so it was a guard against misconfiguration.
however, that decision was canceled and we're always very
careful not to introduce a loop; if a loop does occur, the
worst that can possibly happen is you waste some CPU cycles.
Instead, print (on standard output) what config file is being
used, so the operator can see when an infinite loop occurs.
ALSO:
remove _setcfgarg in load_project_config()
it was used to skip when a target.cfg file didn't exist,
specifically on single-tree projects, but this is now
handled using -f instead, on the while loop inside that
function, so _setcfgarg is now a redundant variable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
these variables are initialised empty, then populated
by reading a configuration file.
it may be that in some cases, we want these variables
to be empty. besides that, the "setcfg" command before
it will throw an error if the module file is missing,
and it is assumed that the variables would be set there.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the next command is a copy, which would give us the error
if the file doesn't exist, and an appropriate message
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is over-engineering, because we do not allow just
about any path to be provided; it's not provided as an
argument in a command, for example.
this is dictated by a configuration file, which we control.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't need to check whether the binary exists, because
make already does that for us.
we still need to check that the directory exists, because
older versions of coreboot did not include kbc1126, and we
do still use older coreboot revisions on some boards.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if injection is attempted, verification comes next,
and verification fails.
this happens for kcma/kgpe amd boards, where pike2008
fake roms are inserted by inserting the correct pci
ids using /dev/null as a source. an empty pike2008 rom
prevents seabios from loading the real pci rom, and this
is done because the real one hangs SeaBIOS.
a similar fix was made for ./vendor download, but
overlooked for ./vendor inject. this patch fixes that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe