This was moved into the application development guide in commit
bf9ceac ("doc: move env_vars into application development").
That commit claimed the following rationale:
No reason why we are duplicating this information in a standalone
guide when we already talk about env variables in the application
developer guide.
A github comment later says the duplication was in "Important build
system variables":
https://github.com/zephyrproject-rtos/zephyr/pull/34364#discussion_r616646517
This is incorrect and a misreading of the application development
guide.
The application development guide is talking about **cmake**
variables. These are not the same thing at all as **environment**
variables; treating them as if they are the same is simply wrong and
misleading, especially the "option 4" part that is really about
CMake variables, not environment variables.
In fact, the separate environment variables page was created for a
reason, which was to have a single place to explain to people unused
to managing their environment how things work, without cluttering
things up for people who already understand this.
There is nothing wrong with small, self-contained guides and in fact I
would argue they are a good thing.
Fix this confusing situation by restoring the original, separate page
and extricating the portions of it that are not related to environment
variables.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Setting variables for console is platform dependent. Having
uninterested platform mixed in is too noisy and hard to read. Follow
"Getting Started Guide" pattern to use tabs to group things.
Getting Started Guide uses "Ubuntu" to reference Linux based platform
but Application Development uses "Linux". This commit doesn't change
the choice of words and sticks to "Linux".
The order of the platfroms is, OTOH, unified to "Linux/macOS" from
"macOS/Linux".
This commit only changes formatting, no wording change.
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
New targets have been added that allow the user to choose a specific
emulator platform. Inform about this in the docs.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
With this commit a dedicated APPLICATION_CONFIG_DIR is added to the
Zephyr build system.
Currently, the APPLICATION_SOURCE_DIR is identical also the base
location of configuration files.
This is very practical for simple samples, but also has it limitations
for more complex setups.
Introducing a dedicated APPLICATION_CONFIG_DIR allows users more
customization options in Zephyr build system.
Especially in terms of custom build configuration files unknown to
Zephyr itself.
For example, instead of all configuration files being located directly
in the application source folder, a project might prefer to organize
their configuration files on a per board basis, for example:
<app>/boards/custom_board_A/prj.conf
<app>/boards/custom_board_A/app.overlay
<app>/boards/custom_board_A/custom_file.mine
<app>/boards/custom_board_B/prj.conf
<app>/boards/custom_board_B/app.overlay
<app>/boards/custom_board_B/custom_file.mine
...
instead of n-files located in the root of the sample.
If the user / sample specifies APPLICATION_CONFIG_DIR, then this folder
will always be used instead of the default configuration folder.
As part of this extension the behaviour of
`-DCONF_FILE=<relative-path>/prj_<build>.conf` and additional Kconfig
fragments automatic sourcing has been aligned with the default behavior
of `prj.conf`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add descriptions for each line in application's CMakeLists.txt. Since
this is the first time a new user is exposed to Zephyr applications
CMakeLists.txt, it's a good time to explain why each line exists.
The descriptions must be for both new Zephyr developers with or
without CMake knowledge.
This commit also moves the comment lines from CMakeLists.txt to the
descriptions to make the file simpler.
ref. #39014
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
Co-authored-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit adds description of the `WARN_EXPERIMENTAL` Kconfig setting
to the application development guide.
It describes the use of `CONFIG_WARN_EXPERIMENTAL` along with an
example of the warning output when experimental features are enabled.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Document that using west outside of a west workspace needs
ZEPHYR_BASE to be set. If this is not set, the instructions
on the "Application Development" page don't work.
Previously, "Getting Started Guide" and "Application Development"
pages told you to run `zephyr-env.sh/zephyr-env.cmd` which would
set ZEPHYR_BASE, but this was removed in Zephyr 2.3.0
Signed-off-by: Daniel Wong <drojfjord@gmail.com>
Move the build and configuration systems under one chapter and reorg the
application developer guide to reflect that.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
No reason why we are duplicating this information in a standalone guide
when we already talk about env variables in the application developer
guide.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The exported structures that were originally introduced for OpenOCD have
since then been reused for other debugger plugins, including PyOCD and
Segger J-Link.
Rename the Kconfig option and the implementation from openocd to debug
thread info, so that it reflects the fact that this is no longer
specifically tied to OpenOCD.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This add documentation for the `-DBOARD=<board>@<revision>` feature.
Organized in a user-visible portion in the application development
guide, and implementation details in the board porting guide.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This is a really useful CMake variable that can be used to preserve
the default CONF_FILE value, but "mix in" additional content.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes: #23825
Today, BOARD, SOC, ARCH, DTS, KCONFIG, and TOOLCHAIN_ROOT can be
specified by users or through other CMake files.
It is not clear if relative paths are permitted and/or from where a
relative path is constructed.
Inside CMake, it is very easy to specify `${ZEPHYR_BASE}`,
`${CMAKE_CURRENT_SOURCE_DIR}`, or similar, thus there is no reason to
use relative path inside CMake, as it easy can lead to discussion on
relative to what.
For users manually invoking CMake using, `cmake ... <app-dir>` it is
nice to have to possibility to specify a relative path.
For this purpose, relative path are considered relative to the
`APPLICATION_SOURCE_DIR`.
This commit updates:
- BOARD_ROOT
- SOC_ROOT
- ARCH_ROOT
- DTS_ROOT
- KCONFIG_ROOT
- TOOLCHAIN_ROOT
to allow paths relative to `APPLICATION_SOURCE_DIR` when specified with
`-D<type>_ROOT=<relative-path>`
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
In some cases it is useful to use the C preprocessor to control the
content of a devicetree file. A specific use case is in testing,
where different combinations of node properties must be checked.
Provide a mechanism to allow arbitrary preprocessor flags to be passed
through CMake to affect the devicetree content.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
In Github issue #27548 I found out that documentation has
incorectness. I made fix and described how correctly provide multiple
overlay files for west and cmake. For both of them necessary to use
quotations. After that, necessary to make one more change if you have
multiple files in quotations. For west necessary to separate multiple
files using spaces and for cmake to separate multiple files necessary
to use semicolons.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
This commit updates the description of SOC_ROOT according to the new
multiple SOC_ROOT enhancement.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
I received feedback that setting e.g. BOARD_ROOT in CMakeLists.txt is
not quite well specified; in particular, it's important to do so
before pulling in the boilerplate via find_package(). Clear that up.
Reported-by: Pete Skeggs <peter.skeggs@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This provides a better error message when building with CMake and
forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package
registry. See parent commit for more details (split from parent for
better readability).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The removal of mentions of 'ext' from the documentation needs an
adjustment in the Eclipse debugging page, since 'modules' is not a
subdirectory of the zephyr base directory.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit changes the current boilerplate include description and
instead describes the use of find_package(Zephyr)
It also add a section covering additional possibilities when using
find_package(Zephyr).
- Search order
- Zephyr repository application description
- Zephyr workspace application description
- Zephyr freestanding application description
- Environment ZEPHYR_BASE setting
- Multiple Zephyr and preference setting
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@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>
The one page on devicetree is too long. Split it into multiple pages
to make it easier to digest and more squintable. This is basically
just moving content around; minimal changes have been made apart from
redoing some transitions and adding a couple of introductory paragraphs.
Rename the 'device-tree' Sphinx :ref: target while we are here.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add a new 'Setting Kconfig configuration values' page in the new Kconfig
section in 'User and Developer Guides'. Move all the information on
setting Kconfig symbols from 'Application Development' and the board
porting guide into it. The same page now covers both configuration files
and Kconfig.defconfig files.
Add links to the new page in various places to make it easy to find.
Also add some more references to the top-level Kconfig page and other
Kconfig pages.
A lot of stuff was rewritten while moving it over (the CONF_FILE
documentation has been cleaned up in particular). Some new information
has been added as well, like a tip re. minimal configurations being
helpful when making Kconfig settings permanent, and a warning re.
dependencies being ORed rather than ANDed when defining a symbol in
multiple locations.
Fixes: #20915
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The SOC Definitions section had backslashes before * in globbing
'source's.
Also change the language for the code block from 'console' to 'none'.
Kconfig isn't shell.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Move the documentation for the menuconfig and guiconfig interfaces from
Application Development to a new Interactive Kconfig Interfaces page in
User and Developer Guides.
Also tweak Application Development to mention the configuration
interfaces earlier. It's good to encourage people to try things out in
menuconfig, because dependencies often get lost when people seldom run
it and just hand-edit files.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The Kconfiglib Kconfig extensions are documented in the porting guide,
which is a pretty weird place to document them. Document them under a
new page in the Kconfig section of User and Developer Guides instead.
Also remove the section about the old Zephyr Kconfig behavior for
defaults (tried last-to-first instead of first-to-last). The behavior
was changed 16 months ago (and was undocumented before that), so it
might not be that useful to mention anymore.
Piggyback misc. small language cleanups and organization nits.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Remove the documentation that incorrectly says that DT uses
Kconfig. DT no longer has access to Kconfig symbols.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Remove the common.dts file which has been used for a year.
common.dts at one point allowed us to conditionally add an MCUBoot
overlay based on Kconfig.
but since DT lost access to Kconfig options it has been unused.
The overridable variable DTS_COMMON_OVERLAYS, which by default points
to common.dts, is also unused in-tree, and any out-of-tree usage can
be ported over to use DTC_OVERLAY_FILE instead, so we remove the
variable as well.
This simplifies the configuration system.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
DTSpec writes this as a single word, presumably to make it easier to
grep for / more precise. Follow along in the rest of the docs now that
our main DT docs page agrees with this usage.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Device tree overlays are a bit of a stumbling block. Try to add more
cross-references and examples for how to use them to the application
development doc and the west build page.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Putting overlay files in the test/sample root clutters the file
system. Allow them to be in the boards subdirectory alongside
board.conf files.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Instead of having a mix of west and CMake/ninja instructions for
building and flashing, document it using only west. This will help
clarify that west is the default build tool in Zephyr and should also
reduce confusion over what tool to use.
Note that the biggest change is changing the default in
doc/extensions/zephyr/application.py for :tool:, from all to west.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The Particle mesh feather boards provide device-tree overlays that
allow individual applications to select the SPI peripheral to be
used for the pins associated with a specific labelled SPI device.
This is necessary because different peripheral instances have slightly
different properties.
Add BOARD_DIR to DTS_ROOTS so these shared files can be located when
included from application-specific overlays.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Clean up some stray references to cmake in doc, boards and
samples that don't make explicit use of the zephyr app extension,
as well as other minor doc fixes.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Make it clearer that the note about setting QEMU_BIN_PATH only applies
if you've got the Zephyr SDK installed.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
There are a few different places where alternatives for setting
environment variables are described. None of them is 100% complete, so
the results are likely to be confusing.
Make a single page on setting environment variables, how the zephyrrc
files work, how the zephyr-env scripts work, and some of the important
environment variables, with appropriate references elsewhere. (This is
inspired by the Arch wiki's excellent page on installing programs.)
Link to it from the getting started and application development pages
instead of repeating the information. This has the benefit of
shortening the getting started guide a bit more.
Add some concrete advice on checking the toolchain environment
variables in particular. This is a stumbling block for beginners.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Add documentation for the new GUI configuration interface in the
Application Development guide.
Also update all the images, touch up the language a bit, and tweak some
minor stuff:
- Say *.conf instead of .conf to make it clearer that .conf isn't the
literal name
- Add a missing -D<board> argument when running cmake
- Use figure:: instead of image::. Comes out left-aligned and with
space between the images, which looks nicer.
- Explain what '- -' and '-*-' means in the terminal menuconfig.
tkinter isn't included by default in many Python installations, despite
being part of the Python standard library, so also add the required
packages to the Development Environment Setup section of the manual. Add
a note to the Application Development section as well, to help
debugging.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The directory tree description was missing a code-block shorthand so the
following lines weren't formatted correctly.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Move to a new guide which will expand on how to submit modules and how
to maintain them.
Also move topology documentation to repository management section where
it fits better.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Just like board's can be placed in out-of-tree BOARD_ROOT's, we now
support DeviceTree sources and bindings being placed in out-of-tree
DTS_ROOT's.
This required for out-of-tree drivers that use DeviceTree.
To implement this we get rid of various user-settable CMake variables
like DTS_APP_BINDINGS, DTS_APP_INCLUDE, and instead have ZEPHYR_BASE,
APPLICATION_SOURCE_DIR and out-of-tree directories conform to using
the same DTS_ROOT concept and directory structure.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a missing reference to how west is used to set ZEPHYR_MODULES in
without-west.rst, augmenting the application development guide a bit
to include this in the list of important variables, cleaning that up a
bit while we are here and adding some more west details.
Add a big fat warning in the getting started guide that using Zephyr
without west is not for the faint of heart.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
A note in the Modules (External projects) section indicated
that in the future it would be possible to do something that
can be already done.
So, let's clarify the note with how it can be done.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
