summaryrefslogtreecommitdiff
path: root/doc
Commit message (Collapse)AuthorAgeFilesLines
* setup.cfg: Use isort to sort our importsbschubert/isortBenjamin Schubert2020-07-031-0/+1
|
* All: Update all references to the mailing list.Tristan van Berkom2020-07-032-7/+6
| | | | | | Update any references to the mailing list to now point to: https://lists.apache.org/list.html?dev@buildstream.apache.org
* docs: Updating documentation regarding junctions and conflicts.Tristan van Berkom2020-06-241-0/+98
| | | | | | | | | | | | | | | This commit: * Redocuments the `junction.py` element almost in it's entirity * Describes the `overrides` feature * Describes how to use `link` elements to derive junction configuration from subprojects. * Adds project.conf documentation for junction `duplicates` * Adds project.conf documentation for junction `internal`
* doc/examples/junction-includes: Renamed project to avoid name conflictTristan van Berkom2020-06-191-1/+1
|
* docs: Updating documentation regarding element names and addressing.Tristan van Berkom2020-06-081-53/+74
| | | | | | | | | | | | | | | | | | | | | | | | | This commit does the following: * Move the section about rules on element naming to the beginning of the document instead of the end. Element names are probably the first thing you need to know about elements, not the last. * Expand this element naming section to also speak about element addressing, and how to express element paths and how these can be used across the boundaries of multiple junctions. It helps to have a single place to discuss this and link to in the documentation, instead of repetitively explaining in multiple places that one must specify a filename relative to a project's element path. * Update documentation about dependencies to refer to the element naming and addressing documentation. * Update the documentation in the `link` and `junction` elements to link back to the element name documentation.
* doc/source/arch_sandboxing.rst: Update for buildbox-runJürg Billeter2020-06-031-33/+24
|
* doc: Adding new `link` plugin to the core plugin indexTristan van Berkom2020-06-011-0/+1
|
* doc/source/using_config.rst: Document support for version specific config files.Tristan van Berkom2020-05-291-0/+11
|
* doc/source/format_declaring.rst: Fixing spelling mistakeTristan van Berkom2020-05-281-4/+4
| | | | | Making some examples more consistent with regards to indentation of YAML, and fixing "recursice -> recursive" spelling mistake.
* doc/source/format_project.rst: Documenting the junction plugin origin.tristan/junction-plugin-originTristan van Berkom2020-05-281-0/+63
|
* testing.py: Add a new `check_cache_key_stability` helperbschubert/cache-key-helperBenjamin Schubert2020-05-121-1/+1
| | | | | This allows plugin authors to implement cache keys tests more easily
* pip.py: Remove the pip element, it is in experimentalBenjamin Schubert2020-05-111-1/+0
| | | | | The pip element was copied already to bst-plugins-experimental. We don't need to have two copies of it.
* downloadablefilesource.py: Make it publicly accessiblebschubert/make-downloadable-filesource-publicBenjamin Schubert2020-05-091-0/+1
| | | | | This is now part of the BuildStream public API and can be used to implement new plugins
* doc/format_project: Add links related to virtual environmentschandan/venv-install-linkChandan Singh2020-05-041-3/+7
| | | | | Add links to Python's official virtual environment tutorial and our BuildStream virtual environment instructions.
* docs/source/format_project.rst: Enhance documentation on plugin origins.Tristan Van Berkom2020-05-041-10/+116
| | | | | | | | | | | | | This patch: * Corrects some out of date documentation about the `local` origin, as this origin no longer has any form of versioning. * Documents the possibility of using version constraints in the `pip` plugin origin. * Adds some documentation about what to be careful of if one uses API unstable plugins via the `pip` plugin origin.
* plugin.py: Rework how deprecation warnings are configured.Tristan Van Berkom2020-05-041-4/+53
| | | | | | | | | | | | | | | | | This is mostly a semantic change which defines how deprecation warnings are suppressed in a more consistent fashion, by declaring such suppressions in the plugin origin declarations rather than on the generic element/source configuration overrides section. Other side effects of this commit are that the warnings have been enhanced to include the provenance of whence the deprecated plugins have been used in the project, and that the custom deprecation message is optional and will appear in the message detail string rather than in the primary warning text, which now simply indicates that the plugin being used is deprecated. Documentation and test cases are updated. This fixes #1291
* Plugin loading refactor, removing all versioningTristan Van Berkom2020-04-291-1/+1
| | | | | | | | | | | | | | | | Plugin format versioning was decided to be removed for local plugins and any plugins for which we do not load an explicitly provided plugin. For pip, this will be handled with a standard distutils/setuptools approach, allowing users to specify pip style version boundaries in the plugin origins. This patch refactors plugin loading so that all related code goes into the private _pluginfactory module, a new small PluginOrigin type was added to better manipulate loaded origins. Test cases have been removed and will be readded in a following commit, adjusted to new expectations.
* doc/source/format_project.rst: Documenting "min-version"Tristan Van Berkom2020-04-251-17/+24
| | | | This replaces "format-version" documentation.
* doc/source/hacking/writing_plugins.rst: Remove some docs about format-versionTristan Van Berkom2020-04-251-15/+0
| | | | | | | This will be done differently in BuildStream 2, as explained in this email: https://mail.gnome.org/archives/buildstream-list/2020-April/msg00017.html
* Remove documentation references to format_versionTristan Van Berkom2020-04-253-60/+0
| | | | | | | | | | | With BuildStream 2.0, we start with a fresh API, everything that is present at the time of the 2.0 release can implicitly be considered to be available since 2.0. In the future, we will be expressing new API additions using the min-version semantic versioning style instead of format version too (so new YAML configurations will be expressed as "since: 2.2" and so on).
* Replace format-version with min-versionTristan Van Berkom2020-04-2515-26/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * "min-version" is specified as a <major>.<minor> point version and uses the installed BuildStream version instead of having a separate versioning number for the format. * The presence of "format-version" is now used to indicate that we might be loading a BuildStream 1 project. * For now, where parsing the version at startup is concerned, and also where `bst init` is concerned, we artificially bump the detected BuildStream version to 2.0 if we detect a version < 2.0, these exceptions can be removed once 2.0 is tagged and released. Summary of changes: _project.py: Now parse "min-version" and detect "format-version" to warn about loading a BuildStream 1 project _versions.py: Remove obsolete BST_FORMAT_VERSION numbers from here data/projectconfig.yaml: Remove old "format-version" from defaults utils.py: Added new private _parse_version() helper function, and another _get_bst_api_version() to get an adjusted API version. frontend/app.py, frontend/cli.py: Updated `bst init` implementation testing (buildstream.testing): Updated testing utilities to generate and use projects with min-version instead of format-version. tests and examples: Updated to use min-version across the board.
* Fix typo namspaceing -> namespacingSean Borg2020-04-211-1/+1
|
* doc/source/hacking/coding_guidelines.rst: Adjusting "Since" guidelines.Tristan Van Berkom2020-04-211-4/+4
| | | | | | | | The guidelines are already correct, however they use 1.x as the reference for this API. This commit simply changes the guidelines to indicate 2.x to contributors as the latest major point release to care about.
* doc/Makefile: Ensure we error out if bst2html.py fails.Tristan Van Berkom2020-04-211-3/+10
| | | | | | | | | | | | | | | | | | The way we were using $(foreach ...) here from GNU Make was causing errors to be ignored, this should really only be used for collecting target names and such. In this commit, we instead: * Collect the SESSION_FILES using $(wildcard ...) * Use a "%.run:" Rule to run bst2html.py for each session file separately, ensuring that we bail out the build if the session generation fails. * Having the SESSION_FILES depend on the phony target sessions-prep, ensures that this rule will be called unconditionally, regardless of the existance of the .run files.
* doc/source/sessions-stored: Refreshing built session filestristan/user-guide-refactorTristan Van Berkom2020-04-1753-683/+2180
| | | | | | | | | This refreshes the stored sessions and adds the new ones generated by recent additions to the user guide. The stored sessions exist to allow contributors to build the docs without having to build the sessions, which requires an internet connection and takes longer to build.
* doc/source/conf.py: Update copyright yearTristan Van Berkom2020-04-171-1/+1
|
* doc/examples/overlaps: Added new user guide entry for overlapping filesTristan Van Berkom2020-04-1716-0/+344
|
* doc/examples/filtering: Added a new user guide entry about filter elementsTristan Van Berkom2020-04-1715-0/+433
|
* doc/examples/composition: Adding user guide about split-rules and compose ↵Tristan Van Berkom2020-04-1717-1/+410
| | | | elements
* doc/examples/strict-mode: Adding a user guide for using non-strict build plansTristan Van Berkom2020-04-1717-0/+507
|
* doc/examples/directives: Add user guide for using project options and directivesTristan Van Berkom2020-04-1710-0/+318
|
* doc/examples/junction-includes: Adding new example about includes with junctionsTristan Van Berkom2020-04-1711-0/+376
|
* doc: Refactoring junction documentationTristan Van Berkom2020-04-1711-97/+177
| | | | | | | | | | | | Renamed the "Advanced topics" section to "Combining projects", and splitting up the junctions section into two separate documents, one which describes the simplest junction example and another which explains how to use workspaces in conjunction with junctions. This commit also makes some minor changes the examples, correcting some grammatical errors, improving links and formatting, also rewording a `note::` in order to clarify that it would be unusual to junction a project that is in a subdirectory.
* doc/source/using_developing.rst: Renamed to "Developing"Tristan Van Berkom2020-04-171-5/+5
| | | | | | | | 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).
* doc/source/using_tutorial.rst: Renamed to "Getting started"Tristan Van Berkom2020-04-171-2/+2
| | | | | | | | | | | | 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.
* doc/source/format_intro.rst: Clarifications around directivesTristan Van Berkom2020-04-171-15/+26
| | | | | | | | | | | | | | 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.
* doc/source/main_glossary.rst: rename 'Core Plugin' -> 'Core plugin'Tristan Van Berkom2020-04-171-2/+2
| | | | Fix an error in documentation build.
* doc/source/main_glossary.rst: Fix docs build errorstristan/fix-docs-build-errorTristan Van Berkom2020-04-111-2/+2
| | | | | Some of the referenced terms within the glossary were not using the capitalization for which the term was declared.
* Docs: Add doc note about directories to core pluginswillsalmon/directorynoteWilliam Salmon2020-02-261-0/+6
|
* exceptions: Expose ErrorDomain, ErrorLoadReasonThomas Coldrick2020-01-231-0/+1
| | | | | | | 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.
* doc/sample_plugin: Update name of entry point groupChandan Singh2020-01-171-4/+1
| | | | | | | | 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.
* Remove "deb" surce plugin, it has beem moved to bst-plugins-experimentaljjardon/move_deb_sourceJavier Jardón2020-01-171-1/+0
|
* Drop support for `setup.py test`Chandan Singh2019-12-231-9/+15
| | | | | | | | | | | | | | 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.
* doc/coding_guidelines: Drop section about line lengthsChandan Singh2019-11-271-15/+0
| | | | | | | 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.
* doc: Add glossary of common termsChandan Singh2019-11-275-0/+141
| | | | | Start a new glossary document, aimed at helping newcomers relevant links to more detailed documents.
* doc/examples/flatpak-autotools: remove references to sdk.gnome.orgAbderrahim Kitouni2019-11-195-8/+8
| | | | download from flathub instead, and update to 1.6 as flathub doesn't include 1.4
* Start linting doc/source/conf.pyChandan Singh2019-11-141-42/+37
| | | | | | | | | | | 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.
* doc/source/hacking: Remove pycodestyle, add BlackChandan Singh2019-11-142-16/+26
| | | | | | | | | | | 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.
* format_project.rst: De-obfuscate element/package differencestlater/plugin-documentation-improvementTristan Maat2019-10-251-1/+1
| | | | | | 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.
* doc/Makefile: exit 1 if running bst command failschiaratolentino/fix-docsctolentino82019-10-071-3/+1
|
View Lorry Controller Status