| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally this was created with also `bootstrap-commands` and
`test-commands` but these were never documented or used.
For `bootstrap-commands`, these originated in baserock but are
basically a part of the `configure-commands` stage, prepending
commands to `configure-commands` is more suitable here since we
now have the prepend/append list directives.
For `test-commands`, these were never used and it's unclear at
this time if it's the correct place for it. It would be interesting
to implement `test-commands` as a separate operation which can run
in parallel with reverse dependency builds (no need to block the
build of a reverse dependency on failing tests, we can still fail
the build as a whole based on a failing test without blocking
builds).
|
| | |
|
| |
|
|
|
| |
It is functionally similar to dict.get() and fulfills the same role, so
it should be used that way.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes the log output more useful, as you see output like this
for each command that is run
+ ./configure --prefix=/usr
...configure output...
+ make
...make output...
etc.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This are nice to see, however need to be improved (see issue #34)
|
| |
|
|
|
|
|
| |
Documented the operations of how BuildElement works in general
as this was missing, also restructured the assemble() method
to not hard code the /buildstream/build and /buildstream/install
paths now that we have Element.get_variable()
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This iterates over the elements dependencies and stages them somewhere
in a sandbox.
This is especially interesting because of the added warnings it gives
you about the file overlaps and ignored files which would otherwise
overwrite non-empty directories.
Also updated build and compose elements to use this in place of
manually looping.
|
| | |
|
| | |
|
| |
|
|
|
| |
Only time one category of command at a time, and status messages
for each command in a group.
|
| | |
|
| |
|
|
|
|
| |
They are loaded with stripped whitespace, but when launching the command
sometimes having a newline can make a difference (especially when
doing cat > file << EOF ... EOF, the final EOF must have a newline)
|
| |
|
|
| |
Only really applies to build elements.
|
| | |
|
| |
|
|
|
|
| |
We were not creating the install directory, and it happened
that most elements dont require it already exist, untill
we met e2fsprogs.bst :)
|
| |
|
|
| |
Matches ybd more closely, but probably doesnt make much difference.
|
| | |
|
| |
|
|
|
| |
Ensure that caches are updated and system is runnable before running
any shell commands.
|
| |
|
|
|
| |
This class implements the running of commands for all of the
subtype plugins which derive it (manual, autotools, cmake, ...)
|
| |
|
|
| |
The core will sort it for us.
|
| |
|
|
|
|
|
|
|
|
| |
This change causes cache keys to be stable (without this
they are different every time due to some random order).
The input of the element does not change if you specify the
install commands before the build commands, and in any case
I dont think we can rely on knowing the order dict members
were specified in a yaml file.
|
| | |
|
|
|
This abstraction allows easily implementing various
subclasses by just installing a config file for their
defaults. It's handy to have it in the core so that
one can easily subclass it in custom plugins.
|
