| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Fails immediately if any command returns non-zero within a project
action.
|
|
|
|
|
|
|
|
|
| |
The project's scripts were never sourced before calling usage(),
causing project_action() to fail.
project_action_usage() should be used only when a project's
scripts have not yet been sourced otherwise its call to
project_include() would be redundant.
|
|
|
|
|
| |
Whenever project_include() is called, it should be done within a
subshell in order to avoid clobbering function definitions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dependencies for any project can be determined by calling
project_dependencies() with a given project and (optional)
arguments. This is the function you will almost always want to call
when you're wanting to collect a list of dependencies. The output of
the topological sort is only one possible ordering of those
dependencies.
'dependencies' files may now contain any number of spaces or tabs
between each argument.
|
|
|
|
|
|
|
|
|
|
| |
Helper functions, such as "arguments", provided by one project should
be callable from another project for more flexibility. Metaprojects in
particular could use this functionality.
In order for this to work, project_include() is used to create the
necessary environment separation (so defined functions are not
clobbered by the helper function).
|
|
|
|
|
|
|
| |
Since we're doing a simple check to see if a function exists in a
given project's scripts we should only source those files into a
subshell (so any changes to the environment are discarded once the
subshell exits).
|
|
|
|
|
|
| |
project_sources_patch() is the equivalent to git_patch() when working
with non-git sources. It should not be used with sources under a
version control system.
|
|
|
|
|
|
|
|
| |
If a path is not supplied to project_sources_patch_recursive() or
git_project_patch_recursive() then it will attempt to apply the set of
patches located at $PROJECTS/$project/$PATCHES (the top-level patches
directory) twice. Checking to see if $path is of non-zero length
avoids this issue.
|
|
|
|
|
|
|
|
| |
The method in which project sources are prepared from either extracted
non-git source archives or sources under $PROJECTS/$project/$SOURCES
are comparable to preparing git sources. This makes knowledge of the
source preparation process mostly transferable across the build
system regardless whether git is involved or not.
|
|
|
|
| |
The extra newlines make actions with no output look strange.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the footer would not print if the project action failed
due to 'set -e' still being in effect (the subshell would return with
a non-zero exit code and exit immediately). The purpose of the
subshell for the project action is to better separate the execution
environment of the project from the library functions it
calls.
The test condition in the if-statement and its consequents were
changed in order to be more concise and informative.
|
|
|
|
|
|
| |
project_blobs_ignore_path() prints nothing if a blobs-ignore file is
not found for the given project and arguments (if any); this behavior
should be the same for project_blobs_path()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following will effectively disable any previous 'set -e':
foo_fail() {
(
set -e
false
true
)
}
if (set +e; foo_fail); then
echo "foo_fail() failed, unsuccessfully"
fi
Creating a subshell within an 'if' statement makes 'set -e'
non-functional.
|
|
|
|
|
|
|
| |
"update" actions were failing ever since revision b7fcc477 for
projects with git sources due to an error in
project_update_check_git() not returning 1 when it determined that the
project's sources was a git repo (to force an update, always).
|
|
|
|
|
| |
If the $install_path directory does not exist or a file which should
be present in the install directory isn't, fail.
|
|
|
|
|
| |
If the $build_path directory does not exist or a file which should be
present in the build directory isn't, fail.
|
|
|
|
|
|
|
|
|
| |
project_action_check() is there to avoid redundant actions from being
performed (e.g., if SeaBIOS is already built, don't build it
again). Since this is its primary purpose, we want to avoid erroring
out when it returns with a non-zero return code.
This addresses issue #614
|
|\ |
|
| |
| |
| |
| |
| |
| | |
If cd fails, nothing else should be done. This is to prevent a
potentially destructive action from being performed on the Libreboot
repository (if the script is executed from the same directory).
|
| |
| |
| |
| |
| | |
Having a specific function for checking whether a patch would apply
isn't that useful if git_am and git_apply call it internally anyway.
|
| |
| |
| |
| |
| |
| | |
git_diff_check() was added for future use since it's complementary to
git_diff_staged_check(). It could be used to check for a dirty
worktree, for example.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The recursive call in git_project_patch_recursive() is now performed
last so that if a patching attempt fails, the calling functions won't
attempt to apply more patches. The consequence of this change is that
patches are applied in (nearly) opposite order from before.
git_project_prepare_patch() is now called after
git_project_prepare_blobs() so that if patching fails and the user
chooses to perform additional project actions anyway, such as
building, the project is already deblobbed and not a risk to their
freedom. I had mistakenly reordered these function calls in a prior
commit.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Executing the project action within its own subshell makes it
easy to abort the action with a simple "exit" while still
allowing for the printing of the footer describing
failure/success. Prevously, if "exit" were called in a project
action the footer would not print.
|
| |
| |
| |
| |
| | |
The "let" builtin returns 1 if it's given an argument that evaluates
to zero.
|
|/ |
|
|
|
|
|
| |
LC_ALL is already set to "C.UTF-8" and exported if libfaketime path is
given in libreboot.conf
|
| |
|
| |
|
|
|
|
|
|
|
| |
Previous patches made certain tests unnecessary due to the setting of
$BRANCH_PREFIX in $branch. By adding the branch prefix right before
it's actually needed we can retain the usefulness of those
conditional tests.
|
|
|
|
|
|
|
|
|
| |
The subshell, changing directory, and checking out was unecessary
considering all of these are done within the functions called by
git_patch()
git_am() was added in order to mirror the same wrapper style as used
by git_apply() and git_commit()
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies git_project_patch_recursive() and provides a unified
method for patching, regardless of the patch format (mailbox or
diff).
Logic is included for dealing with patching failures due to
git_apply_check() not being enough to catch certain edge cases, such
as 'git apply --check' returning 0 but a subsequent 'git apply'
failing.
|
|
|
|
|
|
|
|
|
|
| |
Since changes from an applied diff need to be added to the index and
committed (vs. mailbox files with the git_patch function) new
functions were necessary to account for this difference.
This also fixes a bug where diffs were applied but not committed,
at minimum dirtying the work tree and potentially causing problems for
any later patches.
|
|
|
|
|
|
| |
The previous function, diff_patch_file, was more error-prone and
fragile and did not take into consideration patching of more than one
file at a time(!).
|
|
|
|
|
|
|
|
|
| |
Patching before removing blobs is cleaner since patches are applied
against a freshly created and checked out branch at the specified
revision. Applying patches first also seems to reduce the likelihood
of failed patching attempts due to a nebulous error about files not
matching the git index (but doesn't eliminate it). More debugging
required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the only way patching would work is if for every target
there existed a corresponding directory under $project/$PATCHES, e.g:
"./libreboot update coreboot x200 8MiB corebootfb grub"
would require the "grub" directory and its parents:
"projects/coreboot/patches/x200/8MiB/corebootfb/grub"
Now you only need target-specific patch directories if you need them;
I believe this was the intended behavior.
Superfluous quotes were removed for readability.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a bug where only $project was used as the branch name due to
some faulty logic which checked for the existence of a revision file
before setting the variables "prepare_branch" and "prepare_path".
The bug in this case was that prepare_branch would be set to the value
of $branch in only the first iteration of the for loop since in almost
all cases there is only one revision file that exists for a given
project, regardless of the arguments provided. Explained another way,
in order for the proper branch name to be used a revision file would
have had to exist in every target directory.
This was an issue because only one branch was ever operated on (named
$project), meaning if actions were performed on many targets then only
the last to run would be represented in the project's
repository--making tracking down some bugs a bit harder.
With this fixed we now create a branch for every possible project
or tool configuration and leaves us with a log for each.
|
|
|
|
|
|
|
| |
This is a slight mitigation against branch name collisions. More
robust handling should be added in the future but this is simple
enough and provides some clear indication which branches have been
created by the build system.
|
|
|
|
|
| |
A patch failing to apply shouldn't leave the repository in such a
state where manual intervention is necessary to reset it.
|
|
|
|
| |
Makes it easier to read when multiple terse actions are performed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Projects may now declare other projects it depends upon through
the file "dependencies" located in a project's $CONFIGS directory.
This file requires that each dependency listed, one per line,
correspond to a project in the $PROJECTS directory; the dependency
may be in any form accepted by the libreboot script, e.g:
./libreboot build $dependency
Multiple dependencies files, one per target, are read provided
they are located in target directories and those targets were
included in the list of arguments passed to the libreboot script.
|
|
|
|
|
|
| |
project_file_path() now returns the first matching path rather than
the last. This is necessary to allow splitting up configuration
files for projects into "base" and "overriding" configs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal here is to have fewer full configuration files.
By consolidating the T400 board configs (and board variants such as
the R400/T500/W500) into at most two base configs we can rely on
separate target-specific configs (e.g., for different flash sizes) to
override our default values given in
projects/coreboot/configs/t400/config
File contents of the new configs located at
projects/coreboot/t400/variants/ are now supplied to make as
command-line arguments, overriding the same configurations in the
base config. The T400 file is included as an example of which
configurations need to be overriden by a variant for a proper
SMBIOS name to be used.
Configs allowing for different ROM chip sizes other than the default
are reimplemented in a subsequent commit.
The following are no longer valid targets when building Coreboot:
r400_16mb
r400_8mb
r400_4mb
t400_16mb
t400_8mb
t400_4mb
t500_16mb
t500_8mb
t500_4mb
w500_16mb
w500_8mb
w500_4mb
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the function 'project_release_sources_archive_path'
assumed that a project's source files would always be located within
"$root/$SOURCES" in a directory named after the project. However,
this does not account for projects such as bucts whose source files
are located in "$root/$PROJECTS/$project/sources".
In order to address this, trivial changes were made to leverage
project_sources_path() as it returns nearly all the information needed
to create the path to the archive file.
|
|
|
|
|
|
|
|
|
| |
This is likely one of the very last changes necessary to make the
Libreboot build system more cohesive in appearance.
Hopefully from this point forward it won't be as readily apparent as
to who wrote which parts of the build system (i.e. won't look like a
patchwork quilt any longer).
|
|
|
|
|
|
|
|
|
|
|
|
| |
As an example, do this:
[[ -n $revision ]]
instead of this:
! [[ -z $revision ]]
Makes the code easier to read.
|
|
|
|
|
|
|
|
|
|
| |
There's no benefit to using the POSIX-style '[' test builtin
considering its '-a' and '-o' operators are unused in the Libreboot
build system. Plus, '[[' is safer with respect to any containing file
redirections (for example).
Prior, both '[' and '[[' were used throughout the codebase--a
disparity in usage which this change aims to eliminate.
|
|
|
|
|
|
|
| |
The source builtin provided by Bash is easier to read than '.' (a lone
period). Conforming to POSIX wasn't and isn't a goal of the Libreboot
build system and as such it's fine to deviate from the standard where
it makes sense, such as now.
|