| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to make things easier to find for the
various types of people searching for stuff.
o The installation instructions remain on the main page.
o Three main separate pages have been created
- Using BuildStream
- Authoring BuildStream projects
- Core API reference, for plugin authors
o The "Authoring projects" section swallows the
previous plugin index; so one can find the plugin one
is looking for on the same page as the rest of the format
docs
o The plugin authoring section has been swallowed by the
core API reference section, with a note that this is useful
especially for plugin authors.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issue #183.
Also move the `format-version` related documentation to the first
section "Essentials", beside the project name and element path, since
this is a quite global option it belongs here and not hidden away
with the plugin loading documentation.
Also adjust the main index.rst to include the plugins sub-section
as an adjacent sub-point of the project configuration (consistent
with other project configuration sections).
|
|
|
|
|
|
|
|
|
|
| |
Some of the warnings from sphinx-build are really just warnings,
but a lot of the things we want to avoid and really break documentation,
like broken internal references and some invalid rst directives should
really be errors.
Now we treat all warnings as errors, this should ensure that
any commits landing upstream never break the docs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Packaging is a big topic in the Python community these days. Things are
evolving, but a consensus seems to have formed around the path forward.
With PEP 518, Pip is becoming the primary tool to install Python
modules. In turn, Pip will use the right underlying tool for the job.
(distutils, setuptools, flint, ...)
Given all this, it makes sense to have a pip element in BuildStream.
This element installs a single Python module, telling Pip not to go and
download its dependencies, to make builds reproducible and not rely
on the network during builds.
By default it will use the `pip` command which generally points to Pip
for Python 2. Users can override the "pip" variable, for example to use
the `pip3` command, which generally points to Pip for Python 3.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the 'sources' and 'elements' subdirectores modules technically,
but it does not effect how we load them with pluginbase, that still works.
Updated documentation machinery to have buildstream/plugins in the PYTHONPATH
and import the docs as elements.autotools etc.
This is all because since recent sphinx started importing from distutils,
this was conflicting with our distutils plugin.
|
|
|
|
|
|
| |
This is using the relatively new `sphinx-click` plugin and will
automatically update the documentation based on whatever changes
in the frontend.
|
|
|
|
|
|
|
|
|
|
| |
Instead of documenting this in the Project object, provide a section
more targetted at users. The default configuration is shown in the
user facing documentation and removed from the Project object documentation
which is more targetted at API references for plugin authors.
References to the Project Configuration from the format documentation
have been updated to refer to this new section.
|
|
|
|
|
|
|
| |
Instead of documenting this in the Context object, provide a section
more targetted at users. The default configuration is shown in the
user facing documentation and removed from the Context object documentation
which is more targetted at API references for plugin authors.
|
|
|
|
|
|
| |
Included pedro's docker documentation at the end of this, as
an alternative for those who cannot obtain the base system
requirements to use BuildStream.
|
| |
|
| |
|
|
|
|
|
|
| |
This allows quite manual transformations of input, allowing
one to select a base for the shell and tooling to use and
stage the input separately in order to create some output.
|
|
|
|
| |
Split up General Elements from Build Elements
|
|
|
|
| |
This creates a selective composition of its dependencies.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This element simply stages it's sources and collects a sandbox
relative directory to wrap into an artifact.
|
|
|
|
|
|
|
| |
This just shares some common aspects of being a plugin in buildstream,
allowing some code sharing between Element and Source interfaces.
This class also swallows up the utils node handling utilities.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Sandbox has two implementations: bwrap and chroot
Bwrap has quite a comprehensive implementation,
whereas chroot just covers the basic directory
mappings/mounts.
|
| |
|
|
|
|
|
| |
This also adds the default configuration file and adds a
link to the Project documentation in the docs index
|
|
|
|
|
| |
Needed by both Element and Source implementations, but let's
not give them the whole _yaml API.
|
| |
|
| |
|
|
|
|
|
|
| |
* Remove obnoxious entry in sidebar
* Remove search page access from bottom of
main page, search is available in sidebar
|
|
|
|
|
| |
It's a bit big and wordy, looks like it makes sense to
just call it "Context".
|
| |
|
| |
|