mirror of
https://git.rtems.org/rtems-docs/
synced 2025-05-14 16:59:18 +08:00
Corrections from a review.
This commit is contained in:
Chris Johns
Amar Takhar
parent
c075916ddc
commit
dc234b58f4
@ -30,14 +30,14 @@ For POSIX or Unix hosts the RTEMS Project uses :file:`/opt/rtems` as a standard
|
||||
*prefix*. We view this *prefix* as a production level path and we place
|
||||
development versions under a different *prefix* away from the production
|
||||
versions. Under this top level *prefix* we place the various versions we need
|
||||
for development, for example the version 4.11.0 the *prefix* would be
|
||||
for development, for example the version 4.11.0 *prefix* would be
|
||||
:file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the *prefix*
|
||||
would be :file:`/opt/rtems/4.11.1`. These are recommendations and the choice of
|
||||
what you use is entirly yours. You may decide to have a single path for all
|
||||
RTEMS 4.11 releases of :file:`/opt/rtems/4.11`.
|
||||
|
||||
For Windows a typical prefix is :file:`C:\\opt` and as an MSYS2 path this is
|
||||
:file:`/c/opt`.
|
||||
For Windows a typical prefix is :file:`C:\\opt\\rtems` and as an MSYS2 path
|
||||
this is :file:`/c/opt/rtems`.
|
||||
|
||||
.. _project_sandboxing:
|
||||
|
||||
@ -57,18 +57,8 @@ project directory called :file:`/bd/projects/box-sorter`. Under this create
|
||||
:file:`rtems` and under that create :file:`rtems-4.11.0`. Under this path you
|
||||
can follow the :ref:`released-version` procedure to build a tool set using the
|
||||
prefix of :file:`/bd/projects/box-sorter/rtems/4.11.0`. You are free to create
|
||||
your project specific directories under :file:`/bd/projects/box-sorter`.
|
||||
|
||||
A variation of this is to have a single set of *production* tools and RTEMS
|
||||
BSPs on the disk under :file:`/bd/rtems` you can share between your
|
||||
projects. The top level directories would be:
|
||||
|
||||
:file:`/bd/rtems`
|
||||
The top path to production tools and kernels.
|
||||
|
||||
:file:`/bd/rtems/4.11.0`
|
||||
Production prefix for RTEMS 4.11.0 compiler, debuggers, tools and Board
|
||||
Support Packages (BSPs).
|
||||
your project specific directories under :file:`/bd/projects/box-sorter`. The
|
||||
top level directories would be:
|
||||
|
||||
:file:`/bd/projects`
|
||||
Project specific development trees.
|
||||
@ -76,17 +66,18 @@ projects. The top level directories would be:
|
||||
:file:`/bd/projects/box-sorter`
|
||||
Box Sorter project sandbox.
|
||||
|
||||
A further variation is to use the ``--without-rtems`` option with the RSB to
|
||||
not build the BSPs when building the tools and to buld RTEMS specifically for
|
||||
each project. This lets you have a production tools installed at a top level on
|
||||
your disk and each project can have a specific and possibly customised version
|
||||
of RTEMS. The top level directories would be:
|
||||
:file:`/bd/projects/box-sorter/rtems/4.11.0`
|
||||
Project prefix for RTEMS 4.11.0 compiler, debuggers, tools and installed
|
||||
Board Support Package (BSP).
|
||||
|
||||
A variation is to use the ``--without-rtems`` option with the RSB to not build
|
||||
the BSPs when building the tools and to build RTEMS specifically for each
|
||||
project. This lets you have a production tools installed at a top level on your
|
||||
disk and each project can have a specific and possibly customised version of
|
||||
RTEMS. The top level directories would be:
|
||||
|
||||
:file:`/bd/rtems`
|
||||
The top path to production tools and kernels.
|
||||
|
||||
:file:`/bd/rtems/4.11.0`
|
||||
Production prefix for RTEMS 4.11.0.
|
||||
The top path to production tools.
|
||||
|
||||
:file:`/bd/rtems/4.11.0`
|
||||
Production prefix for RTEMS 4.11.0 compiler, debuggers and tools.
|
||||
@ -100,8 +91,9 @@ of RTEMS. The top level directories would be:
|
||||
:file:`/bd/projects/box-sorter/rtems`
|
||||
Box Sorter project's custom RTEMS kernel source and installed BSP.
|
||||
|
||||
If there is an RTEMS kernel you to share between projects you can move this to
|
||||
a top level and share. In this case you will end up with:
|
||||
A further varation if there is an RTEMS kernel you want to share between
|
||||
projects is it to move this to a top level and share. In this case you will end
|
||||
up with:
|
||||
|
||||
:file:`/bd/rtems`
|
||||
The top path to production tools and kernels.
|
||||
@ -121,9 +113,26 @@ a top level and share. In this case you will end up with:
|
||||
:file:`/bd/projects/box-sorter`
|
||||
Box Sorter project sandbox.
|
||||
|
||||
Finally you can have a single set of *production* tools and RTEMS BSPs on the
|
||||
disk under :file:`/bd/rtems` you can share between your projects. The top level
|
||||
directories would be:
|
||||
|
||||
:file:`/bd/rtems`
|
||||
The top path to production tools and kernels.
|
||||
|
||||
:file:`/bd/rtems/4.11.0`
|
||||
Production prefix for RTEMS 4.11.0 compiler, debuggers, tools and Board
|
||||
Support Packages (BSPs).
|
||||
|
||||
:file:`/bd/projects`
|
||||
Project specific development trees.
|
||||
|
||||
:file:`/bd/projects/box-sorter`
|
||||
Box Sorter project sandbox.
|
||||
|
||||
The project sandoxing approach allows you move a specific production part into
|
||||
the project's sandbox to allow you to customise it. This is useful if you are
|
||||
testing new relesaes. The typical dependency is the order listed above. You can
|
||||
testing new releases. The typical dependency is the order listed above. You can
|
||||
test new RTEMS kernels with production tools but new tools will require you
|
||||
build the kernel with them. Release notes with each release will let know
|
||||
what you need to update.
|
||||
|
||||
@ -14,9 +14,9 @@ RTEMS Project does not maintain binary builds of the tools. This may appear be
|
||||
the opposite to what you normally experience with host operating systems, and
|
||||
it is, however this approach works well. RTEMS is not a host operating system
|
||||
and it is not a distrbution. Providing binary packages for every possible host
|
||||
operating system is to big a task for the RTEMS Project and it is not a good
|
||||
use of the core developer's time. Their time is better spent making RTEMS
|
||||
better and faster.
|
||||
operating system is too big a task for the RTEMS Project and it is not a good
|
||||
use of core developer time. Their time is better spent making RTEMS better and
|
||||
faster.
|
||||
|
||||
Developer Computer
|
||||
------------------
|
||||
@ -207,76 +207,76 @@ Python
|
||||
|
||||
We need Python to build the tools as the RSB is written in Python and we need
|
||||
suitable Python libraries to link to GDB as RTEMS makes use of GDB's Python
|
||||
support. This place specific demands on the Python we need installed and
|
||||
support. This places specific demands on the Python we need installed and
|
||||
available and MSYS2 provides suitable Python versions we can use. You need to
|
||||
make sure you have the correct type and version of Python installed.
|
||||
|
||||
We cannot use the Python executables created by the Python project (python.org)
|
||||
as they are built by Microsoft's C (MSC) compiler. Linking the MSC Python
|
||||
libraries with the MinGW64 executables is not easy and MSYS provided us with a
|
||||
simple solution so we do not support this.
|
||||
| simple solution so we do not support linking MSC libraries.
|
||||
|
||||
MSYS2 provides two types and versions of Python executables, MinGW and MSYS and
|
||||
Python version 2 and 3. For Windows we need the MinGW executable so we have
|
||||
suitables libraries and we have to have Python version 2 because on Windows GDB
|
||||
only builds with Python2.
|
||||
| MSYS2 provides two types and versions of Python executables, MinGW and MSYS and
|
||||
| Python version 2 and 3. For Windows we need the MinGW executable so we have
|
||||
| suitables libraries and we have to have Python version 2 because on Windows GDB
|
||||
| only builds with Python2.
|
||||
|
||||
You also need to install the MSYS version of Python along with the MinGW64
|
||||
Python2 package. The MSYS Python is version 3 and the RSB can support version 2
|
||||
and 3 of Python and it helps handle some of the long paths building GCC can
|
||||
generate.
|
||||
| You also need to install the MSYS version of Python along with the MinGW64
|
||||
| Python2 package. The MSYS Python is version 3 and the RSB can support version 2
|
||||
| and 3 of Python and it helps handle some of the long paths building GCC can
|
||||
| generate.
|
||||
|
||||
Installing MSYS2
|
||||
~~~~~~~~~~~~~~~~
|
||||
| Installing MSYS2
|
||||
| ~~~~~~~~~~~~~~~~
|
||||
|
||||
MSYS2 is installed on a new machine using the MSYS2 installer found on
|
||||
https://msys2.github.io/. Please select the ``x86_64`` variant for 64bit
|
||||
support. Run the installer followin the 7 steps listed on the page.
|
||||
| MSYS2 is installed on a new machine using the MSYS2 installer found on
|
||||
| https://msys2.github.io/. Please select the ``x86_64`` variant for 64bit
|
||||
| support. Run the installer following the 7 steps listed on the page.
|
||||
|
||||
MSYS2 uses the ``pacman`` package manager. The Arch Linux project has detailed
|
||||
documentation on how to use ``pacman``. What is shown here is a just few
|
||||
examples of what you can do.
|
||||
| MSYS2 uses the ``pacman`` package manager. The Arch Linux project has detailed
|
||||
| documentation on how to use ``pacman``. What is shown here is a just few
|
||||
| examples of what you can do.
|
||||
|
||||
.. sidebar:: **Pin MSYS2 Shell to Taskbar**
|
||||
| .. sidebar:: **Pin MSYS2 Shell to Taskbar**
|
||||
|
||||
Pin the MSYS2 64bit Shell to the Taskbar so you always use it rather than
|
||||
the 32bit Shell.
|
||||
| Pin the MSYS2 64bit Shell to the Taskbar so you always use it rather than
|
||||
| the 32bit Shell.
|
||||
|
||||
Open a 64bit MSYS shell from the Start Menu:
|
||||
| Open a 64bit MSYS shell from the Start Menu:
|
||||
|
||||
.. figure:: msys2-minw64-start-menu.png
|
||||
:width: 50%
|
||||
:align: center
|
||||
:alt: MSYS2 64bit Shell Start Menu
|
||||
| .. figure:: msys2-minw64-start-menu.png
|
||||
| :width: 50%
|
||||
| :align: center
|
||||
| :alt: MSYS2 64bit Shell Start Menu
|
||||
|
||||
The packages we require are:
|
||||
| The packages we require are:
|
||||
|
||||
* python
|
||||
* mingw-w64-x86_64-python2
|
||||
* mingw-w64-x86_64-gcc
|
||||
* git
|
||||
* bison
|
||||
* cvs
|
||||
* diffutils
|
||||
* make
|
||||
* patch
|
||||
* tar
|
||||
* texinfo
|
||||
* unzip
|
||||
| * python
|
||||
| * mingw-w64-x86_64-python2
|
||||
| * mingw-w64-x86_64-gcc
|
||||
| * git
|
||||
| * bison
|
||||
| * cvs
|
||||
| * diffutils
|
||||
| * make
|
||||
| * patch
|
||||
| * tar
|
||||
| * texinfo
|
||||
| * unzip
|
||||
|
||||
.. note::
|
||||
| .. note::
|
||||
|
||||
The actual output provided may vary due to changes in the dependent packages
|
||||
or newer package versions.
|
||||
| The actual output provided may vary due to changes in the dependent packages
|
||||
| or newer package versions.
|
||||
|
||||
Install the packages using ``pacman``:
|
||||
| Install the packages using ``pacman``:
|
||||
|
||||
.. code-block:: shell
|
||||
| .. code-block:: shell
|
||||
|
||||
~
|
||||
$ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
|
||||
> bison cvs diffutils git make patch tar texinfo unzip
|
||||
resolving dependencies...
|
||||
| ~
|
||||
| $ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
|
||||
| bison cvs diffutils git make patch tar texinfo unzip
|
||||
| resolving dependencies...
|
||||
looking for conflicting packages...
|
||||
|
||||
Packages (74) db-5.3.28-2 expat-2.1.0-2 gdbm-1.11-3 heimdal-1.5.3-8
|
||||
|
||||
@ -25,14 +25,14 @@ home directory called :file:`/opt/rtems`. This path will require root
|
||||
access. If you are working on a machine you do not have root access to you can
|
||||
use a home directory, :ref:`development-version` has more details about
|
||||
this. If building on Windows use :file:`/c/opt/rtems` to keep the top level
|
||||
paths as sohrt as possible. :ref:`microsoft-windows-installation` provides more
|
||||
paths as short as possible. :ref:`microsoft-windows-installation` provides more
|
||||
detail about path lengths on Windows.
|
||||
|
||||
The location used to install the tools and kernel is called the `prefix`. It is
|
||||
best to have a `prefix` for each different version of RTEMS you are using. If
|
||||
you are using RTEMS 4.11 in production it is not a good to install a
|
||||
development version of 4.12 over the top. A separate `prefix` for each version
|
||||
avoids this.
|
||||
The location used to install the tools and kernel is called the
|
||||
`prefix`. :ref:`prefixes` explains prefixes and how to use them. It is best to
|
||||
have a `prefix` for each different version of RTEMS you are using. If you are
|
||||
using RTEMS 4.11 in production it is not a good to install a development
|
||||
version of 4.12 over the top. A separate `prefix` for each version avoids this.
|
||||
|
||||
Releases download all source packages from the RTEMS FTP server. Hosting all
|
||||
the source on the RTEMS FTP server ensures the source is present for the like
|
||||
@ -41,13 +41,14 @@ RTEMS FTP the RSB will fall back to the packages home site.
|
||||
|
||||
.. note:: **Controlling the RTEMS Kernel Build**
|
||||
|
||||
The RTEMS kernel is built by default for releases. To not build the RTEMS
|
||||
Building releases by default builds the RTEMS kernel. To not build the RTEMS
|
||||
kernel add the ``--without-rtems`` option to the RSB command line.
|
||||
|
||||
By default all the BSPs for an architecture are built. If you only wish to
|
||||
have a specific BSP build you can specify the BSP list by providing to the
|
||||
have a specific BSP built you can specify the BSP list by providing to the
|
||||
RSB the option ``--with-rtemsbsp``. For example to build two BSPs for the
|
||||
SPARC architecture you can supply ``--with-rtemsbsp="erc32 sis"``.
|
||||
SPARC architecture you can supply ``--with-rtemsbsp="erc32 sis"``. This can
|
||||
speed the build time up for some architectures that have a lot of BSPs.
|
||||
|
||||
This procedure will build a SPARC tool chain.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user