| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |
|
|
|
|
| |
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(!).
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
* libs/project
ditto
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In project_action_arguments_recursive(), IFS bindings needed to be
reworked in order to avoid a situation where, for example,
project_extract() would fail to extract source archives (because they
didn't exist), returning a status code of 1 only for it to be masked
by a rebinding of IFS--which would always succeed.
ifs_save and IFS were made local variables in
project_action_arguments_recursive() in order to avoid the need to
rebind IFS after the for loop returns.
This patch makes './libreboot sources <project>' functional.
|
| |
|
|
|
|
|
| |
Located in libs/project, this array's elements are compared with actions
in PROJECTS_ACTIONS_GENERIC when libreboot_setup_project_actions() is
called. This makes it simpler to add/remove actions which
should/shouldn't have a corresponding check function in PROJECT_ACTIONS.
|
| | |
|
| |
|
|
|
|
|
| |
The added function is called after all files in libs/ have been
sourced and provides the correct action sequence for 'test'.
Importantly, this function avoids providing undefined 'usage_check'
and 'clean_check' actions.
|
| |
|
|
|
|
| |
Original naming did not have the '_FUNCTIONS' suffix, which made it
more clear as to the variable's purpose. This change reverts a
previous rename of mine made erroneously.
|
| | |
|
| |
|
|
|
|
| |
The local variable 'arguments' always stores the positional parameters
passed to it as a string, not an array of strings, so usage of "$*"
makes more sense here instead of $@.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Arrays are just a better idea for storing multiple strings than relying
on word splitting. Consequently, several global variables in libs/*
were switched to arrays and any references to said variables modified
to expand to the arrays' elements.
|
| |
|
|
|
|
|
| |
Replace brace expansions with extended globs in a couple of places where
brace expansions were erroneously used in place of actual pattern
matching. This avoids potential errors concerning nonexisting files
when patching sources.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently the name used in a 'for /name/ ...' loop rebinds any local
variables (with the same name) with whatever /name/ is bound
to in a way that persists even after the loop returns. The crux of
the issue here is that a function's children can rebind the parent(s)'
local variables just by using the same name as the variable in a for
loop, which is surprising--and apparently undocumented--behavior.
Use of a subshell group for encapsulating the for loops (See:
project_usage_actions) mitigates the aforementioned issue.
Closes issue: #244
|
