| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
i.e., source tarballs are (partially) supported
|
|
|
|
|
| |
Will help facilitate sane code when handling: archive formats,
checksum file extensions, signature formats.
|
|
|
|
|
| |
This is mainly useful for being able to run these scripts on BSDs.
And for users who use a Bash not installed to /bin.
|
|
|
|
|
| |
This reverts part of pull request #217 which called the 'env'
binary for each printf invocation.
|
|
|
|
|
|
|
|
|
| |
All printf calls should now be properly formatted; prior, the
format specifier string was erroneously used for both the format
specifiers and the string to be printed. 'env' is now used to
locate the printf binary so as to avoid potentially using a shell
builtin. Lastly, all calls to 'echo' within the new build system
have been replaced with printf for consistency/portability purposes.
|
|
|
|
|
|
|
|
|
| |
Modified the function git_project_patch_recursive (in libs/git) to
enable patching with diff files, which uses the new function
diff_patch_file located in libs/common. A generic action script for
bucts is in projects/bucts/. Install/revision/target files are in
projects/bucts/configs/. bucts' merge into the new build system should
be nearly, if not already, complete.
|
| |
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
This is the initial import of the Paper build system into Libreboot.
It was written as a flexible and painless replacement for the Libreboot
build system, allowing to support many different configurations.
It currently only supports the following CrOS devices:
* Chromebook 13 CB5-311 (nyan big)
* Chromebook 14 (nyan blaze)
* Chromebook 11 (HiSense) (veyron jerry)
* Chromebit CS10 (veyron mickey)
* Chromebook Flip C100PA (veyron minnie)
* Chromebook C201PA (veyron speedy)
The build system also supports building various tools and provides
various scripts to ease the installation on CrOS devices.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|