| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Calling this "Developing using BuildStream" is just redundant,
seeing that this is a part of a BuildStream user guide already.
Also, rephrased the introduction text (which appears on a page
which is rarely frequented anyway).
|
|
|
|
|
|
|
|
|
|
|
|
| |
This section of the user manual describes the basics of creating
your first BuildStream project, while we've discussed this in
terms of a "Getting started" guide while developing it, we ended
up naming this a "Tutorial" because of it's walkthrough nature.
Due to it's name as a Tutorial, developers (our target audience)
have a tendency to avoid it and look for more terse and advanced
material, while this material could be more suitable for getting
started.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clarification of (@) include documentation
The "important" annotation here was very confusing to read, rewrote
this section to clarify that files included across a junction cannot
be used to inform the declaration of a junction, as this can present
a circular dependency.
Clarification around conditionals and includes
Clarify that conditional statements are always resolved in the context
of the project where the conditional statement was declared.
|
|
|
|
| |
Fix an error in documentation build.
|
|
|
|
|
| |
Some of the referenced terms within the glossary were not
using the capitalization for which the term was declared.
|
| |
|
|
|
|
|
|
|
| |
Plugin tests are already accessing this API, but using imports from
private modules. For motivation for this to be exposed publicly, note
that ErrorDomain is an argument for most things in runcli.py, and
LoadErrorReason may be another.
|
|
|
|
|
|
|
|
| |
Update sample plugin documentation based on the recent change to entry
point group for plugins.
While I'm here, also remove the unnecessary dependency on `setuptools`
from the sample plugin.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop support for running tests via `setup.py test`, that is considered
deprecated. `tox` is our primary frontend for running tests, so this
change ensures that we don't have to support multiple ways of running
tests.
For testing against a specific installation environment, `tox` is not
quite practical. But in these cases, one can run `pytest` directly. So,
there is no need for this additional indirection.
This was discussed in the following mailing list thread:
https://mail.gnome.org/archives/buildstream-list/2019-December/msg00006.html.
|
|
|
|
|
|
|
| |
Since we format our code using Black, contributors don't have to think
about line lengths themselves. In fact, Black is going to rewrite the
files anyway so it's not even possible to make a judgement call in most
cases.
|
|
|
|
|
| |
Start a new glossary document, aimed at helping newcomers relevant links
to more detailed documents.
|
|
|
|
| |
download from flathub instead, and update to 1.6 as flathub doesn't include 1.4
|
|
|
|
|
|
|
|
|
|
|
| |
Add `doc/source/conf.py` to the filelist for Black and Pylint.
Previously this file was not covered by any of the linters, so this
patch includes one-off sweeping changes for the formatting.
To make pylint happy, we had to disable a warning about defining a
variable called `copyright` since that's a built-in. It's unlikely that
we will ever need the built-in `copyright()` in this module, so it seems
safe to disable it.
|
|
|
|
|
|
|
|
|
|
|
| |
Now that code formatting is managed by Black, and we don't need to run
`pycodestyle` separately, remove corresponding mentions from hacking
documentation.
Add documentation on how to run Black.
Move out linting and formatting into a separate section for better
readability.
|
|
|
|
|
|
| |
When the package and project have the same name, it can be a little
confusing what these things actually mean. This commit makes it a bit
more obvious that the two can (and will often) be different.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now that the frontend has been mostly reworked/standardized,
this patch attempts to put our some guidelines/information in
around UI contributions.
|
|
|
|
|
| |
This patch adds internal cross references for the artifact and
source commands.
|
|
|
|
|
| |
This patch ensures that we document the recently introduced
artifact subcommands "show" and "list-contents".
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Our contributing has got way too big. This patch aims to
split it up into sensible files. These are found in
"Further information".
Closes #1116
|
| |
|
|
|
|
|
| |
bst-1.x support BST_FORMAT_VERSION == 17, as that is not supported by
master I think is ok to set BST_FORMAT_VERSION_MIN = 18
|
| |
|
|
|
|
|
|
| |
This adds documentation on the new keyword `strict` in dependency
declarations, and adds a link to the strict mode user config
section.
|
| |
|
|
|
|
| |
Continuing moving plugins over to bst-plugins-experimental.
|
|
|
|
| |
Continuing moving plugins to bst-plugins-experimental.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was agreed on the mailing list to move all plugins to a single
repository, before moving them into domain-specific repositories. As
a result it seems reasonable to move everything to the
bst-plugins-experimental repo as this stepping stone, rather than
creating a whole new repo.
This commit starts the process of moving things over by moving only the
cmake plugin to bst-plugins-experimental, and altering the tests to
reflect the new location.
|
|
|
|
|
| |
When declaring artifact/source servers which we want to
push to, we must set a "push" boolean
|
| |
|
|
|
|
|
|
| |
`mapping.get_sequence(...).as_str_list()` is a very common
pattern seen both in plugins and the core. Adding a helper to reduce
the number of operations will make usage smoother
|
| |
|
|
|
|
|
| |
Remove completely '_yaml.dump()' and replace all notions and call by
'roundtrip_dump'
|
|
|
|
|
|
| |
One difference is that 'MappingNode.items()' does not strip the
provenance from scalars and lists, which ends up not affecting the
code much.
|
| |
|
|
|
|
| |
Part of #1043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid confusion by not referring to starting another process as
'spawning'. Note that 'spawn' is a process creation method, which is an
alternative to forking.
Say 'create child process' instead of 'fork' where it doesn't harm
understanding. Although we currently only use the 'fork' method for
creating subprocesses, there are reasons for us to support 'spawn' in
the future.
More information on forking and spawning:
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
|