2016-01-28 17:59:49 +01:00
|
|
|
.. _installation_linux:
|
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Install Linux Host Dependencies
|
|
|
|
###############################
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Documentation is available for these Linux distributions:
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-07-25 16:04:17 +02:00
|
|
|
* Ubuntu
|
|
|
|
* Fedora
|
2018-07-10 22:33:06 +02:00
|
|
|
* Clear Linux
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
* Arch Linux
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-07-25 16:04:17 +02:00
|
|
|
For distributions that are not based on rolling releases, some of the
|
|
|
|
requirements and dependencies may not be met by your package manager. In that
|
|
|
|
case please follow the additional instructions that are provided to find
|
|
|
|
software from sources other than the package manager.
|
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. note:: If you're working behind a corporate firewall, you'll likely
|
|
|
|
need to configure a proxy for accessing the internet, if you haven't
|
|
|
|
done so already. While some tools use the environment variables
|
|
|
|
``http_proxy`` and ``https_proxy`` to get their proxy settings, some
|
|
|
|
use their own configuration files, most notably ``apt`` and
|
|
|
|
``git``.
|
|
|
|
|
2016-01-28 17:59:49 +01:00
|
|
|
Update Your Operating System
|
|
|
|
****************************
|
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Ensure your host system is up to date.
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. tabs::
|
|
|
|
|
|
|
|
.. group-tab:: Ubuntu
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo apt-get update
|
|
|
|
sudo apt-get upgrade
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Fedora
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo dnf upgrade
|
2016-08-01 19:08:04 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Clear Linux
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo swupd update
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Arch Linux
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo pacman -Syu
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2018-12-07 08:31:21 +01:00
|
|
|
.. _linux_requirements:
|
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
Install Requirements and Dependencies
|
|
|
|
*************************************
|
|
|
|
|
|
|
|
.. NOTE FOR DOCS AUTHORS: DO NOT PUT DOCUMENTATION BUILD DEPENDENCIES HERE.
|
|
|
|
|
|
|
|
This section is for dependencies to build Zephyr binaries, *NOT* this
|
|
|
|
documentation. If you need to add a dependency only required for building
|
|
|
|
the docs, add it to doc/README.rst. (This change was made following the
|
|
|
|
introduction of LaTeX->PDF support for the docs, as the texlive footprint is
|
|
|
|
massive and not needed by users not building PDF documentation.)
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Note that both Ninja and Make are installed with these instructions; you only
|
|
|
|
need one.
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. tabs::
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Ubuntu
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo apt-get install --no-install-recommends git cmake ninja-build gperf \
|
|
|
|
ccache dfu-util device-tree-compiler wget \
|
2020-05-08 12:56:47 +02:00
|
|
|
python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \
|
2020-02-06 10:56:33 +01:00
|
|
|
make gcc gcc-multilib g++-multilib libsdl2-dev
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Fedora
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo dnf group install "Development Tools" "C Development Tools and Libraries"
|
|
|
|
dnf install git cmake ninja-build gperf ccache dfu-util dtc wget \
|
2020-02-06 10:56:33 +01:00
|
|
|
python3-pip python3-tkinter xz file glibc-devel.i686 libstdc++-devel.i686 \
|
|
|
|
SDL2-devel
|
2017-07-14 16:35:20 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Clear Linux
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo swupd bundle-add c-basic dev-utils dfu-util dtc \
|
|
|
|
os-core-dev python-basic python3-basic python3-tcl
|
2018-07-10 22:33:06 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
The Clear Linux focus is on *native* performance and security and not
|
|
|
|
cross-compilation. For that reason it uniquely exports by default to the
|
|
|
|
:ref:`environment <env_vars>` of all users a list of compiler and linker
|
|
|
|
flags. Zephyr's CMake build system will either warn or fail because of
|
|
|
|
these. To clear the C/C++ flags among these and fix the Zephyr build, run
|
|
|
|
the following command as root then log out and back in:
|
2019-06-25 01:21:28 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2019-06-25 01:21:28 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
echo 'unset CFLAGS CXXFLAGS' >> /etc/profile.d/unset_cflags.sh
|
2019-06-25 01:21:28 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
Note this command unsets the C/C++ flags for *all users on the
|
|
|
|
system*. Each Linux distribution has a unique, relatively complex and
|
|
|
|
potentially evolving sequence of bash initialization files sourcing each
|
|
|
|
other and Clear Linux is no exception. If you need a more flexible
|
|
|
|
solution, start by looking at the logic in
|
|
|
|
``/usr/share/defaults/etc/profile``.
|
2019-06-25 01:21:28 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. group-tab:: Arch Linux
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
.. code-block:: console
|
2017-07-14 16:35:20 +02:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
sudo pacman -S git cmake ninja gperf ccache dfu-util dtc wget \
|
|
|
|
python-pip python-setuptools python-wheel tk xz file make
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
CMake
|
|
|
|
=====
|
|
|
|
|
|
|
|
CMake version 3.13.1 or higher is required. Check what version you have by
|
2019-05-13 22:07:57 +02:00
|
|
|
using ``cmake --version``. If you have an older version, there are several ways
|
2018-12-11 16:33:23 +01:00
|
|
|
of obtaining a more recent one:
|
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
* On Ubuntu, you can follow the instructions for adding the
|
|
|
|
`kitware third-party apt repository <https://apt.kitware.com/>`_
|
|
|
|
to get an updated version of cmake using apt.
|
|
|
|
|
|
|
|
* Download and install a packaged cmake from the CMake project site.
|
|
|
|
(Note this won't uninstall the previous version of cmake.)
|
2018-12-11 16:33:23 +01:00
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
cd ~
|
|
|
|
wget https://github.com/Kitware/CMake/releases/download/v3.15.3/cmake-3.15.3-Linux-x86_64.sh
|
|
|
|
chmod +x cmake-3.15.3-Linux-x86_64.sh
|
|
|
|
sudo ./cmake-3.15.3-Linux-x86_64.sh --skip-license --prefix=/usr/local
|
|
|
|
hash -r
|
|
|
|
|
|
|
|
The ``hash -r`` command may be necessary if the installation script
|
|
|
|
put cmake into a new location on your PATH.
|
2017-10-31 13:35:24 +01:00
|
|
|
|
2018-12-11 16:33:23 +01:00
|
|
|
* Download and install from the pre-built binaries provided by the CMake
|
|
|
|
project itself in the `CMake Downloads`_ page.
|
|
|
|
For example, to install version 3.13.1 in :file:`~/bin/cmake`:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
mkdir $HOME/bin/cmake && cd $HOME/bin/cmake
|
|
|
|
wget https://github.com/Kitware/CMake/releases/download/v3.13.1/cmake-3.13.1-Linux-x86_64.sh
|
|
|
|
yes | sh cmake-3.13.1-Linux-x86_64.sh | cat
|
|
|
|
echo "export PATH=$PWD/cmake-3.13.1-Linux-x86_64/bin:\$PATH" >> $HOME/.zephyrrc
|
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
* Use ``pip3``:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
pip3 install --user cmake
|
|
|
|
|
|
|
|
Note this won't uninstall the previous version of cmake and will
|
|
|
|
install the new cmake into your ~/.local/bin folder so
|
|
|
|
you'll need to add ~/.local/bin to your PATH. (See :ref:`python-pip`
|
|
|
|
for details.)
|
|
|
|
|
2018-12-11 16:33:23 +01:00
|
|
|
* Check your distribution's beta or unstable release package library for an
|
|
|
|
update.
|
|
|
|
|
2019-07-25 12:58:10 +02:00
|
|
|
* On Ubuntu you can also use snap to get the latest version available:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
sudo snap install cmake
|
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
After updating cmake, verify that the newly installed cmake is found
|
|
|
|
using ``cmake --version``.
|
2019-05-13 22:07:57 +02:00
|
|
|
You might also want to uninstall the CMake provided by your package manager to
|
2019-09-12 23:32:29 +02:00
|
|
|
avoid conflicts. (Use ``whereis cmake`` to find other installed
|
|
|
|
versions.)
|
|
|
|
|
|
|
|
DTC (Device Tree Compiler)
|
|
|
|
==========================
|
2017-10-31 13:35:24 +01:00
|
|
|
|
2019-09-12 23:32:29 +02:00
|
|
|
A recent DTC version (1.4.6 or higher) is required. Check what version you
|
2019-07-25 13:03:35 +02:00
|
|
|
have by using ``dtc --version``. If you have an older version, either install a
|
|
|
|
more recent one by building from source, or use the one that is bundled in
|
2020-05-06 22:16:31 +02:00
|
|
|
the :ref:`Zephyr SDK <zephyr_sdk>` by installing it.
|
2019-07-25 13:03:35 +02:00
|
|
|
|
2019-12-11 22:05:54 +01:00
|
|
|
Python
|
|
|
|
======
|
|
|
|
|
|
|
|
Python 3.6 or later is required. Check what version you have by using ``python3
|
|
|
|
--version``.
|
|
|
|
|
|
|
|
If you have an older version, you will need to install a more recent Python 3.
|
|
|
|
You can build from source, or use a backport from your distribution's package
|
|
|
|
manager channels if one is available. Isolating this Python in a virtual
|
|
|
|
environment is recommended to avoid interfering with your system Python.
|
|
|
|
|
|
|
|
.. _pyenv: https://github.com/pyenv/pyenv
|
|
|
|
|
2016-01-28 17:59:49 +01:00
|
|
|
.. _zephyr_sdk:
|
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
Install the Zephyr Software Development Kit (SDK)
|
|
|
|
*************************************************
|
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Use of the Zephyr SDK is optional, but recommended. Some of the dependencies
|
|
|
|
installed above are only needed for installing the SDK.
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Zephyr's :abbr:`SDK (Software Development Kit)` contains all necessary tools to
|
|
|
|
build Zephyr on all supported architectures. Additionally, it includes host
|
|
|
|
tools such as custom QEMU binaries and a host compiler. The SDK supports the
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
following target architectures:
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2016-12-20 15:45:09 +01:00
|
|
|
* :abbr:`X86 (Intel Architecture 32 bits)`
|
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
* :abbr:`Arm (Advanced RISC Machine)`
|
2016-01-28 17:59:49 +01:00
|
|
|
|
|
|
|
* :abbr:`ARC (Argonaut RISC Core)`
|
|
|
|
|
2018-05-31 21:28:07 +02:00
|
|
|
* :abbr:`Nios II`
|
2016-12-20 15:45:09 +01:00
|
|
|
|
2017-05-31 02:43:40 +02:00
|
|
|
* :abbr:`Xtensa`
|
|
|
|
|
2017-09-18 15:49:58 +02:00
|
|
|
* :abbr:`RISC-V`
|
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
Follow these steps to install the Zephyr SDK:
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2020-04-15 18:12:28 +02:00
|
|
|
#. Download the `latest SDK
|
|
|
|
<https://github.com/zephyrproject-rtos/sdk-ng/releases>`_ as a
|
|
|
|
self-extracting installation binary:
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2016-02-13 13:41:34 +01:00
|
|
|
.. code-block:: console
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2020-05-06 22:16:31 +02:00
|
|
|
wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.11.3/zephyr-sdk-0.11.3-setup.run
|
2016-03-15 20:16:06 +01:00
|
|
|
|
2020-05-06 22:16:31 +02:00
|
|
|
(You can change *0.11.3* to another version if needed; the `Zephyr
|
2018-05-31 21:28:07 +02:00
|
|
|
Downloads`_ page contains all available SDK releases.)
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
#. Run the installation binary, installing the SDK at
|
2020-05-06 22:16:31 +02:00
|
|
|
:file:`~/zephyr-sdk-0.11.3`:
|
2016-12-20 15:45:09 +01:00
|
|
|
|
2016-02-13 13:41:34 +01:00
|
|
|
.. code-block:: console
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2018-07-24 20:33:30 +02:00
|
|
|
cd <sdk download directory>
|
2020-05-06 22:16:31 +02:00
|
|
|
chmod +x zephyr-sdk-0.11.3-setup.run
|
|
|
|
./zephyr-sdk-0.11.3-setup.run -- -d ~/zephyr-sdk-0.11.3
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2019-05-13 22:07:57 +02:00
|
|
|
You can pick another directory if you want. If this fails, make sure
|
|
|
|
Zephyr's dependencies were installed as described in `Install Requirements
|
|
|
|
and Dependencies`_.
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2020-05-06 22:16:31 +02:00
|
|
|
If you ever want to uninstall the SDK, just remove the directory where you
|
|
|
|
installed it.
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2020-05-06 22:16:31 +02:00
|
|
|
.. note::
|
|
|
|
It is recommended to install the Zephyr SDK at one of the following locations:
|
2016-01-28 17:59:49 +01:00
|
|
|
|
2020-05-06 22:16:31 +02:00
|
|
|
* ``$HOME/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``$HOME/.local/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``$HOME/.local/opt/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``$HOME/bin/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``/opt/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``/usr/zephyr-sdk[-x.y.z]``
|
|
|
|
* ``/usr/local/zephyr-sdk[-x.y.z]``
|
|
|
|
|
|
|
|
where ``[-x.y.z]`` is optional text, and can be any text, for example ``-0.11.3``.
|
|
|
|
|
|
|
|
If you install the Zephyr SDK outside any of those locations, then it is
|
|
|
|
required to register the Zephyr SDK in the CMake package registry during
|
|
|
|
installation or set :envvar:`ZEPHYR_SDK_INSTALL_DIR` to point to the Zephyr
|
|
|
|
SDK installation folder.
|
|
|
|
|
|
|
|
:envvar:`ZEPHYR_SDK_INSTALL_DIR` can also be used for pointing to a folder
|
|
|
|
containing multiple Zephyr SDKs, allowing for automatic toolchain selection,
|
|
|
|
for example: ``ZEPHYR_SDK_INSTALL_DIR=/company/tools``
|
|
|
|
|
|
|
|
* ``/company/tools/zephyr-sdk-0.11.3``
|
|
|
|
* ``/company/tools/zephyr-sdk-a.b.c``
|
|
|
|
* ``/company/tools/zephyr-sdk-x.y.z``
|
|
|
|
|
|
|
|
this allow Zephyr to pick the right toolchain, while allowing multiple Zephyr
|
|
|
|
SDKs to be grouped together at a custom location.
|
2016-01-28 17:59:49 +01:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
.. _sdkless_builds:
|
2016-02-13 04:24:47 +01:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
Building on Linux without the Zephyr SDK
|
|
|
|
****************************************
|
2016-02-13 04:24:47 +01:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
The Zephyr SDK is provided for convenience and ease of use. It provides
|
|
|
|
toolchains for all Zephyr target architectures, and does not require any extra
|
|
|
|
flags when building applications or running tests. In addition to
|
|
|
|
cross-compilers, the Zephyr SDK also provides prebuilt host tools. It is,
|
|
|
|
however, possible to build without the SDK's toolchain by using another
|
|
|
|
toolchain as as described in the main :ref:`getting_started` document.
|
2016-02-13 04:24:47 +01:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
As already noted above, the SDK also includes prebuilt host tools. To use the
|
2020-05-06 22:16:31 +02:00
|
|
|
SDK's prebuilt host tools with a toolchain from another source, you must set the
|
|
|
|
:envvar:`ZEPHYR_SDK_INSTALL_DIR` environment variable to the Zephyr SDK
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
installation directory. To build without the Zephyr SDK's prebuilt host tools,
|
2020-03-12 23:34:12 +01:00
|
|
|
the :envvar:`ZEPHYR_SDK_INSTALL_DIR` environment variable must be unset.
|
2018-07-24 20:33:30 +02:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
To make sure this variable is unset, run:
|
|
|
|
|
|
|
|
.. code-block:: console
|
2018-07-24 20:33:30 +02:00
|
|
|
|
doc: overhaul getting_started
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
2018-10-15 07:20:24 +02:00
|
|
|
unset ZEPHYR_SDK_INSTALL_DIR
|
2018-05-15 13:14:39 +02:00
|
|
|
|
2020-02-03 22:29:43 +01:00
|
|
|
.. _Zephyr Downloads: https://github.com/zephyrproject-rtos/sdk-ng/releases
|
2018-12-11 16:33:23 +01:00
|
|
|
.. _CMake Downloads: https://cmake.org/download
|