2023-09-25 10:37:35 +00:00
|
|
|
# SPDX-License-Identifier: GPL-3.0-or-later
|
2024-05-26 00:54:36 +00:00
|
|
|
# Copyright (c) 2020-2021,2023-2024 Leah Rowe <leah@libreboot.org>
|
|
|
|
# Copyright (c) 2022 Caleb La Grange <thonkpeasant@protonmail.com>
|
2023-10-07 05:55:10 +00:00
|
|
|
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
eval "$(setvars "" _target rev _xm loc url bkup_url depend tree_depend xtree \
|
|
|
|
mdir subrev subrepo subrepo_bkup)"
|
2023-10-07 05:55:10 +00:00
|
|
|
|
|
|
|
fetch_project_trees()
|
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
_target="$target"
|
|
|
|
[ ! -d "src/$project/$project" ] && x_ mkdir -p "src/$project" \
|
|
|
|
&& fetch_project_repo "$project"
|
2023-10-07 05:55:10 +00:00
|
|
|
fetch_config
|
2024-05-26 00:54:36 +00:00
|
|
|
e "src/$project/$tree" d && return 0
|
2023-10-07 05:55:10 +00:00
|
|
|
prepare_new_tree
|
|
|
|
}
|
|
|
|
|
|
|
|
fetch_config()
|
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
rm -f "$cfgsdir/"*/seen || $err "fetch_config $cfgsdir: !rm seen"
|
2024-01-26 11:15:23 +00:00
|
|
|
eval "$(setvars "" xtree tree_depend)"
|
2023-10-07 05:55:10 +00:00
|
|
|
while true; do
|
|
|
|
eval "$(setvars "" rev tree)"
|
2024-05-26 00:54:36 +00:00
|
|
|
_xm="fetch_config $project/$_target"
|
|
|
|
load_target_config "$_target"
|
|
|
|
[ "$_target" = "$tree" ] && break
|
|
|
|
_target="$tree"
|
2023-10-07 05:55:10 +00:00
|
|
|
done
|
2024-01-21 12:59:02 +00:00
|
|
|
[ -n "$tree_depend" ] && [ "$tree_depend" != "$tree" ] && \
|
2024-01-21 15:50:21 +00:00
|
|
|
x_ ./update trees -f "$project" "$tree_depend"; return 0
|
2023-10-07 05:55:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
load_target_config()
|
|
|
|
{
|
safer, simpler error handling in lbmk
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
|
|
|
[ -f "$cfgsdir/$1/target.cfg" ] || $err "$1: target.cfg missing"
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -f "$cfgsdir/$1/seen" ] && $err "$_xm cfg: infinite loop in trees"
|
2023-10-07 05:55:10 +00:00
|
|
|
|
safer, simpler error handling in lbmk
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
|
|
|
. "$cfgsdir/$1/target.cfg" || $err "load_target_config !$cfgsdir/$1"
|
|
|
|
touch "$cfgsdir/$1/seen" || $err "load_config $cfgsdir/$1: !mk seen"
|
2023-10-07 05:55:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
prepare_new_tree()
|
|
|
|
{
|
2023-12-24 09:04:36 +00:00
|
|
|
printf "Creating %s tree %s (%s)\n" "$project" "$tree" "$_target"
|
2023-10-07 05:55:10 +00:00
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
cp -R "src/$project/$project" "$tmpgit" || \
|
|
|
|
$err "prepare_new_tree $project/$tree: can't make tmpclone"
|
2024-01-01 15:02:34 +00:00
|
|
|
git_prep "$PWD/$cfgsdir/$tree/patches" "src/$project/$tree" "update"
|
2023-10-07 05:55:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fetch_project_repo()
|
|
|
|
{
|
2024-01-26 11:15:23 +00:00
|
|
|
eval "$(setvars "" xtree tree_depend)"
|
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
scan_config "$project" "config/git"
|
safer, simpler error handling in lbmk
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
|
|
|
[ -z "${loc+x}" ] && $err "fetch_project_repo $project: loc not set"
|
|
|
|
[ -z "${url+x}" ] && $err "fetch_project_repo $project: url not set"
|
2023-10-07 05:55:10 +00:00
|
|
|
|
|
|
|
clone_project
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -z "$depend" ] || for d in $depend ; do
|
|
|
|
x_ ./update trees -f $d
|
2023-10-07 05:55:10 +00:00
|
|
|
done
|
2024-05-26 00:54:36 +00:00
|
|
|
rm -Rf "$tmpgit" || $err "fetch_repo: !rm -Rf $tmpgit"
|
2023-10-07 05:55:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
clone_project()
|
|
|
|
{
|
|
|
|
loc="${loc#src/}"
|
2024-05-26 00:54:36 +00:00
|
|
|
loc="src/$loc"
|
|
|
|
e "$loc" d && return 0
|
2023-10-07 05:55:10 +00:00
|
|
|
|
2024-01-01 15:02:34 +00:00
|
|
|
git clone $url "$tmpgit" || git clone $bkup_url "$tmpgit" \
|
2024-05-26 00:54:36 +00:00
|
|
|
|| $err "clone_project: could not download $project"
|
2024-01-01 15:02:34 +00:00
|
|
|
git_prep "$PWD/config/$project/patches" "$loc"
|
2023-10-07 05:55:10 +00:00
|
|
|
}
|
2023-09-25 10:37:35 +00:00
|
|
|
|
2024-01-01 15:02:34 +00:00
|
|
|
git_prep()
|
2023-09-25 11:17:02 +00:00
|
|
|
{
|
2024-01-01 15:02:34 +00:00
|
|
|
_patchdir="$1"
|
|
|
|
_loc="$2"
|
|
|
|
|
safer, simpler error handling in lbmk
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
|
|
|
[ -z "${rev+x}" ] && $err "git_prep $_loc: rev not set"
|
|
|
|
git -C "$tmpgit" reset --hard $rev || $err "git -C $_loc: !reset $rev"
|
|
|
|
git_am_patches "$tmpgit" "$_patchdir" || $err "!am $_loc $_patchdir"
|
2024-01-01 15:02:34 +00:00
|
|
|
|
2024-01-01 16:42:35 +00:00
|
|
|
if [ "$project" != "coreboot" ] || [ $# -gt 2 ]; then
|
2024-05-22 16:59:42 +00:00
|
|
|
prep_submodules "$_loc"
|
|
|
|
fi
|
|
|
|
|
2024-05-22 17:50:42 +00:00
|
|
|
[ "$project" = "coreboot" ] && [ -n "$xtree" ] && [ $# -gt 2 ] && \
|
|
|
|
[ "$xtree" != "$tree" ] && link_crossgcc "$_loc"
|
2024-01-01 15:02:34 +00:00
|
|
|
|
2024-05-19 22:04:37 +00:00
|
|
|
[ "$xbmk_release" = "y" ] && [ "$_loc" != "src/$project/$project" ] \
|
|
|
|
&& rmgit "$tmpgit"
|
|
|
|
|
2024-05-22 22:11:12 +00:00
|
|
|
move_repo "$_loc"
|
2024-01-01 10:30:19 +00:00
|
|
|
}
|
|
|
|
|
2024-05-22 16:59:42 +00:00
|
|
|
prep_submodules()
|
|
|
|
{
|
2024-05-22 17:03:48 +00:00
|
|
|
[ -f "$tmpgit/.gitmodules" ] || return 0
|
2024-05-22 16:59:42 +00:00
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
mdir="$PWD/config/submodule/$project"
|
2024-05-22 14:56:35 +00:00
|
|
|
[ -n "$tree" ] && mdir="$mdir/$tree"
|
2024-05-19 23:10:27 +00:00
|
|
|
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
if [ -f "$mdir/module.list" ]; then
|
|
|
|
cat "$mdir/module.list" > "$tmpdir/modules" || \
|
|
|
|
$err "!cp $mdir/module.list $tmpdir/modules"
|
|
|
|
else
|
|
|
|
git -C "$tmpgit" submodule status | awk '{print $2}' > \
|
|
|
|
"$tmpdir/modules" || $err "$mdir: cannot list submodules"
|
|
|
|
fi
|
2024-05-19 23:10:27 +00:00
|
|
|
|
2024-05-22 14:56:35 +00:00
|
|
|
while read -r msrcdir; do
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
fetch_submodule "$msrcdir"
|
|
|
|
patch_submodule "$msrcdir"
|
2024-05-19 23:10:27 +00:00
|
|
|
done < "$tmpdir/modules"
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
|
|
|
|
# some build systems may download more (we want to control it)
|
|
|
|
rm -f "$tmpgit/.gitmodules" || $err "!rm .gitmodules as per: $mdir"
|
|
|
|
}
|
|
|
|
|
|
|
|
fetch_submodule()
|
|
|
|
{
|
|
|
|
mcfgdir="$mdir/${1##*/}"
|
|
|
|
eval "$(setvars "" subrev subrepo subrepo_bkup)"
|
|
|
|
|
|
|
|
[ ! -f "$mcfgdir/module.cfg" ] || . "$mcfgdir/module.cfg" || \
|
|
|
|
$err "! . $mcfgdir/module.cfg"
|
|
|
|
|
|
|
|
if [ -n "$subrepo" ] || [ -n "$subrepo_bkup" ]; then
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -n "$subrev" ] || $err "$1, $mdir: subrev not defined"
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
|
|
|
|
rm -Rf "$tmpgit/$1" || $err "!rm '$mdir' '$1'"
|
|
|
|
for mod in "$subrepo" "$subrepo_bkup"; do
|
|
|
|
[ -z "$mod" ] && continue
|
|
|
|
git clone "$mod" "$tmpgit/$1" || rm -Rf "$tmpgit/$1" \
|
|
|
|
|| $err "!rm $mod $project $cfgdir $1"
|
2024-05-24 20:43:10 +00:00
|
|
|
[ -d "$tmpgit/$1" ] && break
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
done
|
|
|
|
[ -d "$tmpgit/$1" ] || $err "!clone $mod $project $mcfgdir $1"
|
|
|
|
else
|
2024-05-26 00:54:36 +00:00
|
|
|
git -C "$tmpgit" submodule update --init --checkout -- "$1" \
|
|
|
|
|| $err "$mdir: !update $1"
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
patch_submodule()
|
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -z "$subrev" ] || git -C "$tmpgit/$1" reset --hard "$subrev" || \
|
|
|
|
$err "$mdir $1: cannot reset git revision"
|
git.sh: allow finer control of git submodules
in each submodule configuration directory, a module.cfg
file can now be provided. in it, the user can specify
two repository links (main and backup) and a revision, like
so:
subrepo="repo link goes here"
subrepo_bkup="backup repo link goes here"
subrev="git revision id goes here"
additionally:
in the *main* project directory for the submodules,
a module.list file can be provided. example entries:
3rdparty/vboot
3rdparty/libgfxinit
if the module.list file is provided, only those submodules
will be downloaded. this can be combined with the module.cfg
files, if you wish, but it's optional. you can mix and match.
example locations:
multi-tree project:
config/submodule/coreboot/default/module.list
config/submodule/coreboot/default/vboot/module.cfg
single-tree project:
config/submodule/flashprog/module.list
config/submodule/flashprog/foo/module.cfg
*no* configuration files have been provided, in this commit,
which means that the current behaviour is maintained.
follow-up commits will absolutely configure the submodules.
this is being done to reduce the number of modules downloaded,
because we don't use most of the coreboot submodules that are
downloaded, thus wasting bandwidth and the releases are also
much bigger than necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24 16:50:42 +00:00
|
|
|
|
|
|
|
git_am_patches "$tmpgit/$1" "$mdir/${1##*/}/patches"
|
2024-05-19 23:10:27 +00:00
|
|
|
}
|
|
|
|
|
2023-09-25 10:37:35 +00:00
|
|
|
git_am_patches()
|
|
|
|
{
|
2024-01-01 14:14:25 +00:00
|
|
|
for _patch in "$2/"*; do
|
|
|
|
[ -L "$_patch" ] || [ ! -f "$_patch" ] || git -C "$1" am \
|
2024-05-26 00:54:36 +00:00
|
|
|
"$_patch" || $err "$1 $2: !git am $_patch"; continue
|
2023-09-25 10:37:35 +00:00
|
|
|
done
|
2024-01-01 14:14:25 +00:00
|
|
|
for _patches in "$2/"*; do
|
|
|
|
[ ! -L "$_patches" ] && [ -d "$_patches" ] && \
|
|
|
|
git_am_patches "$1" "$_patches"; continue
|
2023-09-25 11:00:43 +00:00
|
|
|
done
|
2023-09-25 10:37:35 +00:00
|
|
|
}
|
2024-05-22 22:08:13 +00:00
|
|
|
|
|
|
|
link_crossgcc()
|
|
|
|
{
|
|
|
|
(
|
|
|
|
cd "$tmpgit/util" || $err "prep $1: !cd $tmpgit/util"
|
|
|
|
rm -Rf crossgcc || $err "prep $1: !rm xgcc"
|
|
|
|
ln -s "../../$xtree/util/crossgcc" crossgcc || $err "$1: !xgcc link"
|
|
|
|
) || $err "$1: !xgcc link"
|
|
|
|
}
|
2024-05-22 22:11:12 +00:00
|
|
|
|
|
|
|
move_repo()
|
|
|
|
{
|
|
|
|
[ "$1" = "${1%/*}" ] || x_ mkdir -p "${1%/*}"
|
|
|
|
mv "$tmpgit" "$1" || $err "git_prep: !mv $tmpgit $1"
|
|
|
|
[ -n "$xtree" ] && [ ! -d "src/coreboot/$xtree" ] && \
|
|
|
|
x_ ./update trees -f coreboot "$xtree"; return 0
|
|
|
|
}
|