Although a project's default revision is still "master", we can change
some examples around to refer to "main" branches instead, in keeping
with the changes we're making for Zephyr more generally.
We cannot change the default project revision away from "master" in
west v0.10.x, because that would be a schema change. That will have to
wait for v0.11.0.
However, in the meantime, we are making some inclusive language
changes related to 'west init', because the --mr option is not
governed by a schema. These will be documented in the next commit.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Adjust these for 0.10. This version parses differently as a string vs.
as a float. Document that quoting the value avoids the issue. Make
some other adjustments and improvements for clarity.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The west 0.9 documentation for group-filter states:
Only the top level manifest file’s manifest: group-filter:
value has any effect. The manifest: group-filter: values in any
imported manifests are ignored.
This turns out to have been a mistake, because all users who import a
manifest which makes some projects inactive will have to also manually
disable the same groups just to get the same default list of projects.
Example manifest fragments showing the issue:
# my/west.yml
manifest:
projects:
- name: upstream
import: true
and:
# upstream/west.yml
manifest:
group-filter: [-disabled-group]
projects:
- name: i-want-this
- name: i-do-not-want-this
groups:
- disabled-group
As written, my/west.yml will include 'i-do-not-want-this' as an
active project.
This kind of leaky faucet has proven to be an unintuitive and poor
user experience. Users expect to get the default projects without
having to copy the group-filter for everything they import.
We can't reverse this behavior without pushing out a new schema
version, however: manifest schema 0.9, and therefore west 0.9.x, is
doomed to this bad behavior.
What we'll do to move past this is create a new schema version 0.10
that does the right thing, document the 0.10 behavior, and discourage
combining these two features in west 0.9.x.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Move the content related to handling imports that refer to multiple
files handled to right after the ordered list which defines the order
that manifests are imported. The current placement at the end of this
docs section was poorly chosen.
Create subsections for how projects and extensions are decided in the
final resolved manifest.
The project revisions in the top level example manifest fragment are
not important here. Remove them for clarity.
The top level manifest file need not be named west.yml now; adjust
accordingly.
This is prep work for adding a new subsection for group-filter.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The documentation suggests that 'west update PROJECT' can be done if
PROJECT is defined from some imported manifest. That's actually not
true. Fix it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This diff is deceptively complicated. No text is being added or
removed; the only thing that's being done is that the entire 'Manifest
Imports' section is being moved down below the groups and submodules
sections.
This is prep work for a later commit which will document revised
semantics for mixing 'import' with 'group-filter'. This will make
'group-filter' values compose across imports, so it will be useful to
have documentation for group and group-filter before documentation for
imports. That will let us document the way they work together within
the 'Manifest Imports' section without using concepts that haven't yet
been defined.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Though BOARD_FLASH_RUNNER and BOARD_DEBUG_RUNNER are documented in the
debug host tools page, these variables are important enough to deserve
mention in the section dedicated to choosing a runner. Make it so.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Create tables and Sphinx sections for the sub-keys of a manifest.
List the subsections in the same order they are documented.
This makes it easier to jump around in the document from the table of
contents and see what's in each subkey.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We haven't updated the example revisions in the alternate topologies
sections in a while. Update these for the upcoming 2.5 release.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
With the documentation for west 0.9, the 'basics' page is completely
out of control. Reorganize it so it fits in a few pages, moving many
details out into other pages for the truly curious.
As part of this, create new pages for built-in commands (built-in.rst)
and esoteric details about workspaces (workspaces.rst).
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rename the 'basics' page to basics.rst, adding a redirect for the old
title.
Rearrange some other index pages to improve the flow:
- Put relatively stale content in moving-to-west.rst to the bottom. I
expect pepole have either moved west or are choosing not to.
- Promote the release notes page higher up, since that seems more
important.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These Git refs are used by west as a scratch space. Let that be known,
but don't make any other guarantees.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
West 0.9, now with submodules!
This is a new feature which allows you to incorporate a project's Git
submodules into the workspace.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a new feature that allows you to associate projects with
groups, then force west to ignore a subset of the projects list by
disabling project groups. This can be selectively overridden via
configuration file to make west stop ignoring the projects within an
individual workspace.
An example use case is to define a project whose Git repository
requires credentials to pull. Putting such a project in a group named
"foo" and disabling group "foo" would make "west update" ignore the
project unless the user specifically configures the workspace to allow
"foo". After that, "west update" will pull the project as usual.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The west manifest import feature now uses the terms "allowlist" and
"blocklist" instead of "whitelist" and "blacklist", respectively.
The old terms are still supported by the tool for compatibility, but
the docs for this feature are going to use the new terms exclusively.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The west update docs mix together the steps for updating a project
with the set of projects that are being updated. This is inconvenient
now that west 0.9 has a concept of inactive projects.
Split the content into a part that describes *which* projects are
updated, and a separate part that describes how *each* project is
updated.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Try to spell out the implications of that a bit more clearly.
Suggested-by: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fix the documentation of the usage of --*-file, which were renamed from
--kernel-*.
Fixes#31630.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The previous and short description wasn't enough for me to understand
the interesting trade-off of --keep-descendants, thanks to
@mbolivar-nordic for clarifying this on Slack.
For reference this option was added in west commit 11b8588303 part of
https://github.com/zephyrproject-rtos/west/pull/165/
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Various improvements to the west repo-tool.rst page and pages that
link to it:
Rename the page title to "Basics", since it documents, well the
basics, including built-in commands like "help" an "config" that are
not directly related to multiple repositories.
The "multi-repo" term was invented before we started using
"workspace". Drop it from the text and rework things using words like
"workspace", "basics", or "built-ins" instead, which read better.
We've been using west for a long enough time that justifying its
existence prominently at the start of this page is no longer
necessary; move that to the "dustbin of history" page (why.rst).
Try harder to clarify exactly what a "project" is, along with other
workspace related clarifications.
Improve the documentation for the west init and west update commands,
and create :ref: targets for linking directly to them for convenience
elsewhere in the docs.
Slim down the usages for other built-in commands, so we don't have to
keep those up to date as carefully each release. This is about to be
important for west 0.9, which is going to change the detailed
semantics for the "[PROJECT ...]" part of each command synopsis in a
way that will be inconvenient to duplicate for each of these.
Move the "Topologies supported" content lower down. Try to help the
reading flow by letting people get familiar with a workspace and what
you can do with it using the Zephyr GSG workspace that they probably
already have before overwhelming them with other possibilities and
choices.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The debugging section was generalized for flash and debugging tools.
The links were refactored accordly and all references were updated.
To be consistent, the directory doc/guides/debbugging was renamed to
doc/guides/flash_debug.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
It's great to have full manifest examples that can actually work as they
are, however the number of lines can "dilute" the feature currently
described and distract from it. Add some comments in the manifests to
highlight the current topic(s).
The file tree examples and their descriptions are carefully made up and
generally excellent, however I found my eyes going constantly back and
forth between the two in order to match them with one another and build
the actual, graphical representation in my head. These new comments
attached to the major elements of the trees will IMHO accelerate that
visual representation. What I found especially lacking: clues about
which directories are .git/ clones; a pity in the pages specifically
about git clone organization.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Use italics more consistently when referring to parameters by name.
Make the ImportFlag members appear.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
How to manage repositories that require authentication to fetch from
using west is a frequently asked question.
TL;DR on the answer is that Git already has credential storage built
in, so our expectation is that there is nothing west needs to do in
particular, as users can select whatever credential helper works for
them, or set up a custom one using something like the GIT_ASKPASS
environment variable.
That's not a very helpful expectation if people aren't aware that
credential helpers exist, though, so let's document that and provide
examples for common use cases, as well as west-specific
troubleshooting advice.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Depending on how people set up their Python, west might not be on
PATH.
I'd like to have a special-purpose step by step guide for how to
handle this in the documentation to save support time when this
happens. I think it's worth special casing since west is the first
runnable program that pip installs onto a new user's system when
they're following the GSG.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
When this west doc page was written, we didn't have any documentation
for modules. We do now, so point to it instead of CMake.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
"why can't I run west build" is a common enough question to add an FAQ
item for it in the troubleshooting page.
Even if people don't read it, we can still link to it on Slack etc.
when the question gets asked.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The board porting guide now has useful information on supporting
flash/debug commands. Link to it from the top of the page describing
these commands to hopefully make it easier to find.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is joint work with Kumar Gala (see signed-off-by).
Document the changes to the generated node macros in macros.bnf,
moving the old file to legacy-macros.bnf and putting it in its own
section.
The actual generated macros are now a low-level detail, so rewrite the
foregoing sections as examples in terms of the new <devicetree.h> APIs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This nomenclature change was done in west 0.7 because it seems to be a
lot easier for people to understand. Propagate it to all the west
documentation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
