rtems/rtems-docs
1
0
Fork 0
mirror of https://git.rtems.org/rtems-docs/ synced 2025-05-15 11:56:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

RSB: Finish reformatting after moving from asciidocs.

Browse Source
This commit is contained in:
Chris Johns 2016-11-02 12:09:54 +11:00
parent 75e787d4a0
commit 8b64335986
11 changed files with 3527 additions and 3497 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
rsb/bug-reporting.rst Normal file
View File

@ -0,0 +1,61 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
.. _Bugs, Crashes, and Build Failures:
Bugs, Crashes, and Build Failures
#################################
The RTEMS Source Builder is a Python program and every care is taken to test
the code however bugs, crashes, and build failures can and do happen. If you
find a bug please report it via the :r:url:`devel` or email on the RTEMS Users
list.
Please include the generated RSB report. If you see the following a report has
been generated::
...
...
Build FAILED <1>
See error report: rsb-report-4.11-rtems-lm32.txt <2>
.. topic:: Items:
1. The build has failed.
2. The report's file name.
The generated report contains the command line, version of the RSB, your host's
``uname`` details, the version of Python and the last 200 lines of the log.
If for some reason there is no report please send please report the following:
- Command line,
- The git hash,
- Host details with the output of the ``uname -a`` command,
- If you have made any modifications.
If there is a Python crash please cut and paste the Python backtrace into the
bug report. If the tools fail to build please locate the first error in the log
file. This can be difficult to find on hosts with many cores so it sometimes
pays to re-run the command with the ``--jobs=none`` option to get a log that is
correctly sequenced. If searching the log file seach for ``error:`` and the
error should be just above it.
.. _Contributing:
Contributing
############
We welcome all users adding, fixing, updating and upgrading packages and their
configurations. The RSB is open source and open to contributions. These can be
bug fixes, new features or new configurations. Please break patches down into
changes to the core Python code, configuration changes or new configurations.
Please email patches generated using git so your commit messages and you are
acknowledged as the contributor.

323
rsb/commands.rst Normal file
View File

@ -0,0 +1,323 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
Commands
########
Checker (sb-check)
~~~~~~~~~~~~~~~~~~
This commands checks your system is set up correctly. Most options are ignored::
$ ../source-builder/sb-check --help
sb-check: [options] [args]
RTEMS Source Builder, an RTEMS Tools Project (c) 2012-2013 Chris Johns
Options and arguments:
--force : Force the build to proceed
--quiet : Quiet output (not used)
--trace : Trace the execution
--dry-run : Do everything but actually run the build
--warn-all : Generate warnings
--no-clean : Do not clean up the build tree
--always-clean : Always clean the build tree, even with an error
--jobs : Run with specified number of jobs, default: num CPUs.
--host : Set the host triplet
--build : Set the build triplet
--target : Set the target triplet
--prefix path : Tools build prefix, ie where they are installed
--topdir path : Top of the build tree, default is $PWD
--configdir path : Path to the configuration directory, default: ./config
--builddir path : Path to the build directory, default: ./build
--sourcedir path : Path to the source directory, default: ./source
--tmppath path : Path to the temp directory, default: ./tmp
--macros file[,[file] : Macro format files to load after the defaults
--log file : Log file where all build out is written too
--url url[,url] : URL to look for source
--no-download : Disable the source downloader
--targetcflags flags : List of C flags for the target code
--targetcxxflags flags : List of C++ flags for the target code
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
--with-<label> : Add the --with-<label> to the build
--without-<label> : Add the --without-<label> to the build
--regression : Set --no-install, --keep-going and --always-clean
$ ../source-builder/sb-check
RTEMS Source Builder - Check, v0.2.0
Environment is ok
Defaults (sb-defaults)
~~~~~~~~~~~~~~~~~~~~~~
This commands outputs and the default macros for your when given no
arguments. Most options are ignored::
$ ../source-builder/sb-defaults --help
sb-defaults: [options] [args]
RTEMS Source Builder, an RTEMS Tools Project (c) 2012-2013 Chris Johns
Options and arguments:
--force : Force the build to proceed
--quiet : Quiet output (not used)
--trace : Trace the execution
--dry-run : Do everything but actually run the build
--warn-all : Generate warnings
--no-clean : Do not clean up the build tree
--always-clean : Always clean the build tree, even with an error
--jobs : Run with specified number of jobs, default: num CPUs.
--host : Set the host triplet
--build : Set the build triplet
--target : Set the target triplet
--prefix path : Tools build prefix, ie where they are installed
--topdir path : Top of the build tree, default is $PWD
--configdir path : Path to the configuration directory, default: ./config
--builddir path : Path to the build directory, default: ./build
--sourcedir path : Path to the source directory, default: ./source
--tmppath path : Path to the temp directory, default: ./tmp
--macros file[,[file] : Macro format files to load after the defaults
--log file : Log file where all build out is written too
--url url[,url] : URL to look for source
--no-download : Disable the source downloader
--targetcflags flags : List of C flags for the target code
--targetcxxflags flags : List of C++ flags for the target code
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
--with-<label> : Add the --with-<label> to the build
--without-<label> : Add the --without-<label> to the build
--regression : Set --no-install, --keep-going and --always-clean
Set Builder (sb-set-builder)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This command builds a set::
$ ../source-builder/sb-set-builder --help
RTEMS Source Builder, an RTEMS Tools Project (c) 2012-2013 Chris Johns
Options and arguments:
--force : Force the build to proceed
--quiet : Quiet output (not used)
--trace : Trace the execution
--dry-run : Do everything but actually run the build
--warn-all : Generate warnings
--no-clean : Do not clean up the build tree
--always-clean : Always clean the build tree, even with an error
--regression : Set --no-install, --keep-going and --always-clean
---jobs : Run with specified number of jobs, default: num CPUs.
--host : Set the host triplet
--build : Set the build triplet
--target : Set the target triplet
--prefix path : Tools build prefix, ie where they are installed
--topdir path : Top of the build tree, default is $PWD
--configdir path : Path to the configuration directory, default: ./config
--builddir path : Path to the build directory, default: ./build
--sourcedir path : Path to the source directory, default: ./source
--tmppath path : Path to the temp directory, default: ./tmp
--macros file[,[file] : Macro format files to load after the defaults
--log file : Log file where all build out is written too
--url url[,url] : URL to look for source
--no-download : Disable the source downloader
--no-install : Do not install the packages to the prefix
--targetcflags flags : List of C flags for the target code
--targetcxxflags flags : List of C++ flags for the target code
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
--with-<label> : Add the --with-<label> to the build
--without-<label> : Add the --without-<label> to the build
--mail-from : Email address the report is from.
--mail-to : Email address to send the email too.
--mail : Send email report or results.
--smtp-host : SMTP host to send via.
--no-report : Do not create a package report.
--report-format : The report format (text, html, asciidoc).
--bset-tar-file : Create a build set tar file
--pkg-tar-files : Create package tar files
--list-bsets : List available build sets
--list-configs : List available configurations
--list-deps : List the dependent files.
The ``arguments`` are a list of build sets to build.
**Options**:
``--force``:
Force the build to proceed even if the host check fails. Typically this
happens if executable files are found in the path at a different location to
the host defaults.
``--trace``:
Trace enable printing of debug information to stdout. It is really only of
use to RTEMS Source Builder's developers.
``--dry-run``:
Do everything but actually run the build commands. This is useful when
checking a new configuration parses cleanly.
``--warn-all``:
Generate warnings.
``--no-clean``:
Do not clean up the build tree during the cleaning phase of the build. This
leaves the source and the build output on disk so you can make changes, or
amend or generate new patches. It also allows you to review configure type
output such as ``config.log``.
``--always-clean``:
Clean away the results of a build even if the build fails. This is normally
used with ``--keep-going`` when regression testing to see which build sets
fail to build. It keeps the disk usage down.
``--jobs``:
Control the number of jobs make is given. The jobs can be ``none`` for only 1
job, ``half`` so the number of jobs is half the number of detected cores, a
fraction such as ``0.25`` so the number of jobs is a quarter of the number of
detected cores and a number such as ``25`` which forces the number of jobs to
that number.
``--host``:
Set the host triplet value. Be careful with this option.
``--build``:
Set the build triplet. Be careful with this option.
``--target``:
Set the target triplet. Be careful with this option. This is useful if you
have a generic configuration script that can work for a range of
architectures.
``--prefix path``:
Tools build prefix, ie where they are installed.
``--topdir path``:
Top of the build tree, that is the current directory you are in.
``--configdir path``:
Path to the configuration directory. This overrides the built in defaults.
``--builddir path``:
Path to the build directory. This overrides the default of +build+.
``--sourcedir path``:
Path to the source directory. This overrides the default of +source+.
``--tmppath path``:
Path to the temporary directory. This overrides the default of +tmp+.
``--macros files``:
Macro files to load. The configuration directory path is searched.
``--log file``:
Log all the output from the build process. The output is directed to +stdout+
if no log file is provided.
``--url url``:
URL to look for source when downloading. This is can be comma separate list.
``--no-download``:
Disable downloading of source and patches. If the source is not found an
error is raised.
``--targetcflags flags``:
List of C flags for the target code. This allows for specific local
customisation when testing new variations.
``--targetcxxflags flags``:
List of C++ flags for the target code. This allows for specific local
customisation when testing new variations.
``--libstdcxxflags flags``:
List of C++ flags to build the target libstdc++ code. This allows for
specific local customisation when testing new variations.
``--with-<label>``:
Add the ``--with-<label>`` to the build. This can be tested for in a script
with the ``%bconf_with`` macro.
``--without-<label>``:
Add the ``--without-<label>`` to the build. This can be tested for in a
script with the ``%bconf_without`` macro.
``--mail-from``:
Set the from mail address if report mailing is enabled.
``--mail-to``:
Set the to mail address if report mailing is enabled. The report is mailed to
this address.
``--mail``:
Mail the build report to the mail to address.
``--smtp-host``:
The SMTP host to use to send the email. The default is ``localhost``.
``--no-report``:
Do not create a report format.
``--report-format format``:
The report format can be ``text`` or ``html``. The default is ``html``.
``--keep-going``:
Do not stop on error. This is useful if your build sets performs a large
number of testing related builds and there are errors.
``--always-clean``:
Always clean the build tree even with a failure.
``--no-install``:
Do not install the packages to the prefix. Use this if you are only after the
tar files.
``--regression``:
A convenience option which is the same as ``--no-install``, ``--keep-going``
and ``--always-clean``.
``--bset-tar-file``:
Create a build set tar file. This is a single tar file of all the packages in
the build set.
``--pkg-tar-files``:
Create package tar files. A tar file will be created for each package built
in a build set.
``--list-bsets``:
List available build sets.
``--list-configs``:
List available configurations.
``--list-deps``:
Print a list of dependent files used by a build set. Dependent files have a
``dep[?]` prefix where ``?`` is a number. The files are listed alphabetically.
Set Builder (sb-builder)
~~~~~~~~~~~~~~~~~~~~~~~~
This command builds a configuration as described in a configuration
file. Configuration files have the extension of ``.cfg``::
$ ./source-builder/sb-builder --help
sb-builder: [options] [args]
RTEMS Source Builder, an RTEMS Tools Project (c) 2012 Chris Johns
Options and arguments:
--force : Force the build to proceed
--quiet : Quiet output (not used)
--trace : Trace the execution
--dry-run : Do everything but actually run the build
--warn-all : Generate warnings
--no-clean : Do not clean up the build tree
--always-clean : Always clean the build tree, even with an error
--jobs : Run with specified number of jobs, default: num CPUs.
--host : Set the host triplet
--build : Set the build triplet
--target : Set the target triplet
--prefix path : Tools build prefix, ie where they are installed
--topdir path : Top of the build tree, default is $PWD
--configdir path : Path to the configuration directory, default: ./config
--builddir path : Path to the build directory, default: ./build
--sourcedir path : Path to the source directory, default: ./source
--tmppath path : Path to the temp directory, default: ./tmp
--macros file[,[file] : Macro format files to load after the defaults
--log file : Log file where all build out is written too
--url url[,url] : URL to look for source
--targetcflags flags : List of C flags for the target code
--targetcxxflags flags : List of C++ flags for the target code
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
--with-<label> : Add the --with-<label> to the build
--without-<label> : Add the --without-<label> to the build
--list-configs : List available configurations

1515
rsb/configuration.rst Normal file
View File

File diff suppressed because it is too large Load Diff

98
rsb/cross-canadian-cross.rst Normal file
View File

@ -0,0 +1,98 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
Cross and Canadian Cross Building
#################################
Cross building and Canadian Cross building is the process of building on one
machine an executable that runs on another machine. An example is building a
set of RTEMS tools on Linux to run on Windows. The RSB supports cross building
and Canadian cross building.
This sections details how to the RSB to cross and Canadian cross build.
Cross Building
~~~~~~~~~~~~~~
Cross building is where the _build_ machine and _host_ are different. The
_build_ machine runs the RSB and the _host_ machine is where the output from
the build runs. An example is building a package such as NTP for RTEMS on your
development machine.
To build the NTP package for RTEMS you enter the RSB command::
$ ../source-builder/sb-set-builder \
--log=log_ntp_arm.txt \
--prefix=$HOME/development/rtems/4.11 \ <1>
--host=arm-rtems4.11 \ <2>
--with-rtems-bsp=xilinx_zynq_zc706 \ <3>
4.11/net/ntp
.. topic:: Items:
1. The tools and the RTEMS BSP are installed under the same prefix.
2. The ``--host`` command is the RTEMS architecture and version.
3. The BSP is built and installed in the prefix. The arhcitecture must match
the ``--host`` architecture.
.. note: Installing Into Different Directories
If you install BSPs into a different path to the prefix use the
``--with-tools`` option to specify the path to the tools. Do not add the
'bin' directory at the end of the path.
Canadian Cross Building
~~~~~~~~~~~~~~~~~~~~~~~
A Canadian cross builds are where the **build**, **host** and **target**
machines all differ. For example building an RTEMS compiler for an ARM
processor that runs on Windows is built using a Linux machine. The process is
controlled by setting the build triplet to the host you are building, the host
triplet to the host the tools will run on and the target to the RTEMS
architecture you require. The tools needed by the RSB are:
- Build host C and C++ compiler
- Host C and C++ cross compiler
The RTEMS Source Builder requires you provide the build host C and C++ compiler
and the final host C and C++ cross-compiler. The RSB will build the build host
RTEMS compiler and the final host RTEMS C and C++ compiler, the output of this
process.
The Host C and C++ compiler is a cross-compiler that builds executables for the
host you want the tools for. You need to provide these tools. For Windows a
number of Unix operating systems provide MinGW tool sets as packages.
The RSB will build an RTEMS tool set for the build host. This is needed when
building the final host's RTEMS compiler as it needs to build RTEMS runtime
code such as *libc* on the build host.
TIP: Make sure the host's cross-compiler tools are in your path before run the
RSB build command.
TIP: Canadian Cross built tools will not run on the machine being used to build
them so you should provide the ``--bset-tar-files`` and ``--no-install``
options. The option to not install the files lets you provide a prefix that
does not exist or you cannot access.
To perform a cross build add ``--host=`` to the command line. For example
to build a MinGW tool set on FreeBSD for Windows add ``--host=mingw32``
if the cross compiler is ``mingw32-gcc``::
$ ../source-builder/sb-set-builder --host=mingw32 \
--log=l-mingw32-4.11-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
4.11/rtems-sparc
If you are on a Linux Fedora build host with the MinGW packages installed the
command line is::
$ ../source-builder/sb-set-builder --host=i686-w64-mingw32 \
--log=l-mingw32-4.11-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
4.11/rtems-sparc

24
rsb/history.rst Normal file
View File

@ -0,0 +1,24 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
History
#######
The RTEMS Source Builder is a stand alone tool based on another tool called the
'SpecBuilder'. The SpecBuilder was written for the RTEMS project to give me a
way to build tools on hosts that did not support RPMs. At the time the RTEMS
tools maintainer only used spec files to create various packages. This meant I
had either spec files, RPM files or SRPM files. The RPM and SPRM files where
useless because you needed an 'rpm' type tool to extract and manage them. There
are versions of 'rpm' for a number of non-RPM hosts however these proved to be
in various broken states and randomly maintained. The solution I settled on was
to use spec files so I wrote a Python based tool that parsed the spec file
format and allowed me to create a shell script I could run to build the
package. This approach proved successful and I was able to track the RPM
version of the RTEMS tools on a non-RPM host over a number of years. however
the SpecBuilder tool did not help me build tools or other packages not related
to the RTEMS project where there was no spec file I could use so I needed
another tool. Rather than start again I decided to take the parsing code for
the spec file format and build a new tool called the RTEMS Source Builder.

346
rsb/hosts.rst Normal file
View File

@ -0,0 +1,346 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
.. _Hosts:
Hosts
#####
The known supported hosts are listed in the following sections. If a host or a
new version of a host is known to work and it not listed please lets us know.
Linux
~~~~~
A number of different Linux distrubutions are known to work. The following have
been tested and report as working.
.. _ArchLinux:
ArchLinux
^^^^^^^^^
The following packages are required on a fresh Archlinux 64bit installation::
# pacman -S base-devel gdb xz unzip ncurses git zlib
Archlinux, by default installs ``texinfo-5`` which is incompatible for building
GCC 4.7 tree. You will have to obtain ``texinfo-legacy`` from ``AUR`` and
provide a manual override::
# pacman -R texinfo
$ yaourt -S texinfo-legacy
# ln -s /usr/bin/makeinfo-4.13a /usr/bin/makeinfo
.. _CentOS:
CentOS
^^^^^^
The following packages are required on a minimal CentOS 6.3 64bit installation::
# yum install autoconf automake binutils gcc gcc-c++ gdb make patch \
bison flex xz unzip ncurses-devel texinfo zlib-devel python-devel git
The minimal CentOS distribution is a specific DVD that installs a minimal
system. If you use a full system some of these packages may have been
installed.
.. _Fedora:
Fedora
^^^^^^
The RTEMS Source Builder has been tested on Fedora 19 64bit with the following
packages::
# yum install ncurses-devel python-devel git bison gcc cvs gcc-c++ \
flex texinfo patch perl-Text-ParseWords zlib-devel
.. _Raspbian:
Raspbian
^^^^^^^^
The is the Debian distribution for the Raspberry Pi. The following packages are
required::
$ sudo apt-get install autoconf automake bison flex binutils gcc g++ gdb \
texinfo unzip ncurses-dev python-dev git
It is recommended you get Model B of the Pi with 512M of memory and to mount a
remote disk over the network. The tools can be built on the network disk with a
prefix under your home directory as recommended and end up on the SD card.
.. _Ubuntu:
.. _Xubuntu:
Ubuntu
^^^^^^
The latest version is Ubuntu 16.04.1 LTS 64bit. This section also includes
Xubuntu. A minimal installation was used and the following packages installed::
$ sudo apt-get build-dep binutils gcc g++ gdb unzip git
$ sudo apt-get install python2.7-dev
.. _Linux Mint:
Linux Mint
^^^^^^^^^^
zlib package is required on Linux Mint. It has a different name (other
than the usual zlib-dev)::
# sudo apt-get install zlib1g-dev
.. _openSUSE:
openSUSE
^^^^^^^^
This has been reported to work but no instructions were provided. This is an
opportunity to contribute. Please submit any guidance you can provide.
.. _FreeBSD:
FreeBSD
~~~~~~~
The RTEMS Source Builder has been tested on FreeBSD 9.1, 10.3 and 11 64bit
version. You need to install some ports. They are::
# cd /usr/ports
# portinstall --batch lang/python27
If you wish to build Windows (mingw32) tools please install the following
ports::
# cd /usr/ports
# portinstall --batch devel/mingw32-binutils devel/mingw32-gcc
# portinstall --batch devel/mingw32-zlib devel/mingw32-pthreads
The +zlip+ and +pthreads+ ports for MinGW32 are used for builiding a Windows
QEMU.
If you are on FreeBSD 10.0 and you have pkgng installed you can use 'pkg
install' rather than 'portinstall'.
.. _NetBSD:
NetBSD
~~~~~~
The RTEMS Source Builder has been tested on NetBSD 6.1 i386. Packages to add
are::
# pkg_add ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/6.1/devel/gmake-3.82nb7.tgz
# pkg_add ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/6.1/devel/bison-2.7.1.tgz
# pkg_add ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/6.1/archivers/xz-5.0.4.tgz
.. _MacOS:
MacOS
~~~~~
The RTEMS Source Builder has been tested on Mountain Lion. You will need to
install the Xcode app using the *App Store* tool, run Xcode and install the
Developers Tools package within Xcode.
.. _Mavericks:
Mavericks
^^^^^^^^^
The RSB works on Mavericks and the GNU tools can be built for RTEMS using the
Mavericks clang LLVM tool chain. You will need to build and install a couple of
packages to make the RSB pass the +sb-check+. These are CVS and XZ. You can get
these tools from a packaging tool for MacOS such as *MacPorts* or *HomeBrew*.
I do not use 3rd party packaging on MacOS and prefer to build the packages from
source using a prefix of ``/usr/local``. There are good 3rd party packages around
however they sometimes bring in extra dependence and that complicates my build
environment and I want to know the minimal requirements when building
tools. The following are required:
. The XZ package's home page is http://tukaani.org/xz/ and I use version
5.0.5. XZ builds and installs cleanly.
Serria
^^^^^^
The RSB works on Serria with the latest Xcode.
.. _Windows:
Windows
~~~~~~~
Windows tool sets are supported. The tools are native Windows executable which
means they do not need an emulation layer to run once built. The tools
understand and use standard Windows paths and integrate easily into Windows IDE
environments because they understand and use standard Windows paths. Native
Windows tools have proven over time to be stable and reliable with good
performance. If you are a Windows user or you are required to use Windows you
can still develop RTEMS application as easily as a Unix operating system. Some
debugging experiences may vary and if this is an issue please raised the topic
on the RTEMS Users mailing list.
Building the tools or some other packages may require a Unix or POSIX type
shell. There are a few options, Cygwin and MSYS2. I recommend MSYS2.
.. _MSYS2:
MSYS2
^^^^^
This is a new version of the MinGW project's original MSYS. MSYS2 is based
around the Arch Linux pacman packager. MSYS and MSYS2 are a specific fork of
the Cygwin project with some fundamental changes in the handling of paths and
mounts that allow easy interaction between the emulated POSIX environment and
the native Windows environment.
Install MSYS2 using the installer you can download from
https://msys2.github.io/. Follow the instructions on the install page and make
sure you remove any global path entries to any other Cygwin, MinGW, MSYS or
packages that may uses a Cygwin DLL, for example some ports of Git.
To build the tools you need install the following packages using pacman::
$ pacman -S git cvs bison make texinfo patch unzip diffutils tar \
mingw64/mingw-w64-x86_64-gcc mingw64/mingw-w64-x86_64-binutils
To build make sure you add '--without-python --jobs=none' to the standard RSB
command line. MSYS2 has a temp file name issue and so the GNU AR steps on
itself when running in parallel on SMP hardware which means we have to set the
jobs option to none.
Install a suitable version of Python from http://www.python.org/ and add it to
the start of your path. The MSYS2 python does not work with waf.
.. _Cygwin:
Cygwin
Building on Windows is a little more complicated because the Cygwin shell is
used rather than the MSYS2 shell. The MSYS2 shell is simpler because the
detected host triple is MinGW so the build is a standard cross-compiler build.
A Canadian cross-build using Cygwin is supported if you would like native
tools or you can use a Cygwin built set of tools.
Install a recent Cygwin version using the Cygwin setup tool. Select and install
the groups and packages listed:
.. table:: Cygwin Packages
======= =========================
Group Package
Archive bsdtar
Archive unzip
Archive xz
Devel autoconf
Devel autoconf2.1
Devel autoconf2.5
Devel automake
Devel binutils
Devel bison
Devel flex
Devel gcc4-core
Devel gcc4-g++
Devel git
Devel make
Devel mingw64-x86_64-binutils
Devel mingw64-x86_64-gcc-core
Devel mingw64-x86_64-g++
Devel mingw64-x86_64-runtime
Devel mingw64-x86_64-zlib
Devel patch
Devel zlib-devel
MinGW mingw-zlib-devel
Python python
======= =========================
The setup tool will add a number of dependent package and it is ok to accept
them.
Disabling Windows Defender improves performance if you have another up to date
virus detection tool installed and enabled. The excellent ``Process Hacker 2``
tool can monitor the performance and the Windows Defender service contributed a
high load. In this case a 3rd party virus tool was installed so the Windows
Defender service was not needed.
To build a MinGW tool chain a Canadian cross-compile (Cxc) is required on
Cygwin because the host is Cygwin therefore a traditional cross-compile will
result in Cygiwn binaries. With a Canadian cross-compile a Cygwin
cross-compiler is built as well as the MinGW RTEMS cross-compiler. The Cygwin
cross-compiler is required to build the C runtime for the RTEMS target because
we are building under Cygiwn. The build output for an RTEMS 4.10 ARM tool set
is::
chris@cygthing ~/development/rtems/src/rtems-source-builder/rtems
$ ../source-builder/sb-set-builder --log=l-arm.txt --prefix=$HOME/development/rtems/4.10 4.10/rtems-arm
RTEMS Source Builder - Set Builder, v0.2
Build Set: 4.10/rtems-arm
config: expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-w64-mingw32-1
building: expat-2.1.0-x86_64-w64-mingw32-1
reporting: expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-w64-mingw32-1.html
config: tools/rtems-binutils-2.20.1-1.cfg
package: arm-rtems4.10-binutils-2.20.1-1 <1>
building: arm-rtems4.10-binutils-2.20.1-1
package: (Cxc) arm-rtems4.10-binutils-2.20.1-1 <2>
building: (Cxc) arm-rtems4.10-binutils-2.20.1-1
reporting: tools/rtems-binutils-2.20.1-1.cfg ->
arm-rtems4.10-binutils-2.20.1-1.html
config: tools/rtems-gcc-4.4.7-newlib-1.18.0-1.cfg
package: arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1
building: arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1
package: (Cxc) arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1
building: (Cxc) arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1
reporting: tools/rtems-gcc-4.4.7-newlib-1.18.0-1.cfg ->
arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1.html
config: tools/rtems-gdb-7.3.1-1.cfg
package: arm-rtems4.10-gdb-7.3.1-1
building: arm-rtems4.10-gdb-7.3.1-1
reporting: tools/rtems-gdb-7.3.1-1.cfg -> arm-rtems4.10-gdb-7.3.1-1.html
config: tools/rtems-kernel-4.10.2.cfg
package: arm-rtems4.10-kernel-4.10.2-1
building: arm-rtems4.10-kernel-4.10.2-1
reporting: tools/rtems-kernel-4.10.2.cfg -> arm-rtems4.10-kernel-4.10.2-1.html
installing: expat-2.1.0-x86_64-w64-mingw32-1 -> /cygdrive/c/Users/chris/development/rtems/4.10
installing: arm-rtems4.10-binutils-2.20.1-1 -> /cygdrive/c/Users/chris/development/rtems/4.10 <3>
installing: arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1 -> /cygdrive/c/Users/chris/development/rtems/4.10
installing: arm-rtems4.10-gdb-7.3.1-1 -> /cygdrive/c/Users/chris/development/rtems/4.10
installing: arm-rtems4.10-kernel-4.10.2-1 -> /cygdrive/c/Users/chris/development/rtems/4.10
cleaning: expat-2.1.0-x86_64-w64-mingw32-1
cleaning: arm-rtems4.10-binutils-2.20.1-1
cleaning: arm-rtems4.10-gcc-4.4.7-newlib-1.18.0-1
cleaning: arm-rtems4.10-gdb-7.3.1-1
cleaning: arm-rtems4.10-kernel-4.10.2-1
Build Set: Time 10:09:42.810547 <4>
.. topic:: Items:
1. The Cygwin version of the ARM cross-binutils.
2. The +(Cxc)+ indicates this is the MinGW build of the package.
3. Only the MinGW version is installed.
4. Cygwin is slow so please be patient. This time was on an AMD Athlon 64bit
Dual Core 6000+ running at 3GHz with 4G RAM running Windows 7 64bit.
.. warning::
Cygwin documents the 'Big List Of Dodgy Apps' or 'BLODA'. The link is
http://cygwin.com/faq/faq.html#faq.using.bloda and it is worth a look. You
will see a large number of common pieces of software found on Windows systems
that can cause problems. My testing has been performed with NOD32 running and
I have seen some failures. The list is for all of Cygwin so I am not sure
which of the listed programs effect the RTEMS Source Biulder. The following
FAQ item talks about *fork* failures and presents some technical reasons they
cannot be avoided in all cases. Cygwin and it's fork MSYS are fantastic
pieces of software in a difficult environment. I have found building a single
tool tends to work, building all at once is harder.

8
rsb/index.rst
View File

@ -36,6 +36,14 @@ to the Community Project hosted at http://www.rtems.org/.
:numbered: :numbered:
source-builder source-builder
quick-start
hosts
project-sets
cross-canadian-cross
third-party-packages
configuration
commands
bug-reporting
* :ref:`genindex` * :ref:`genindex`
* :ref:`search` * :ref:`search`

240
rsb/project-sets.rst Normal file
View File

@ -0,0 +1,240 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
Project Sets
############
The RTEMS Source Builder supports project configurations. Project
configurations can be public or private and can be contained in the RTEMS
Source Builder project if suitable, other projects they use the RTEMS Source
Builder or privately on your local file system.
The configuration file loader searches the macro ``_configdir`` and by default
this is set to ``%{_topdir}/config:%{_sbdir}/config`` where ``_topdir`` is the
your current working direct, in other words the directory you invoke the RTEMS
Source Builder command in, and ``_sbdir`` is the directory where the RTEMS
Source Builder command resides. Therefore the ``config`` directory under each
of these is searched so all you need to do is create a ``config`` in your
project and add your configuration files. They do not need to be under the
RTEMS Source Builder source tree. Public projects are included in the main
RTEMS Source Builder such as RTEMS.
You can also add your own ``patches`` directory next to your ``config``
directory as the ``%patch`` command searches the ``_patchdir`` macro variable
and it is by default set to ``%{_topdir}/patches:%{_sbdir}/patches``.
The ``source-builder/config`` directory provides generic scripts for building
various tools. You can specialise these in your private configurations to make
use of them. If you add new generic configurations please contribute them back
to the project
Bare Metal
~~~~~~~~~~
The RSB contains a 'bare' configuration tree and you can use this to add
packages you use on the hosts. For example 'qemu' is supported on a range of
hosts. RTEMS tools live in the ``rtems/config`` directory tree. RTEMS packages
include tools for use on your host computer as well as packages you can build
and run on RTEMS.
The **bare metal** support for GNU Tool chains. An example is the
``lang/gcc491`` build set. You need to provide a target via the command line
``--target`` option and this is in the standard 2 or 3 tuple form. For example
for an ARM compiler you would use ``arm-eabi`` or ``arm-eabihf`, and for SPARC
you would use `sparc-elf`::
$ cd rtems-source-builder/bare
$ ../source-builder/sb-set-builder --log=log_arm_eabihf \
--prefix=$HOME/development/bare --target=arm-eabihf lang/gcc491
RTEMS Source Builder - Set Builder, v0.3.0
Build Set: lang/gcc491
config: devel/expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-apple-darwin13.2.0-1
building: expat-2.1.0-x86_64-apple-darwin13.2.0-1
config: devel/binutils-2.24-1.cfg
package: arm-eabihf-binutils-2.24-1
building: arm-eabihf-binutils-2.24-1
config: devel/gcc-4.9.1-newlib-2.1.0-1.cfg
package: arm-eabihf-gcc-4.9.1-newlib-2.1.0-1
building: arm-eabihf-gcc-4.9.1-newlib-2.1.0-1
config: devel/gdb-7.7-1.cfg
package: arm-eabihf-gdb-7.7-1
building: arm-eabihf-gdb-7.7-1
installing: expat-2.1.0-x86_64-apple-darwin13.2.0-1 -> /Users/chris/development/bare
installing: arm-eabihf-binutils-2.24-1 -> /Users/chris/development/bare
installing: arm-eabihf-gcc-4.9.1-newlib-2.1.0-1 -> /Users/chris/development/bare
installing: arm-eabihf-gdb-7.7-1 -> /Users/chris/development/bare
cleaning: expat-2.1.0-x86_64-apple-darwin13.2.0-1
cleaning: arm-eabihf-binutils-2.24-1
cleaning: arm-eabihf-gcc-4.9.1-newlib-2.1.0-1
cleaning: arm-eabihf-gdb-7.7-1
RTEMS
~~~~~
The RTEMS Configurations found in the ``rtems`` directory. The configurations
are grouped by RTEMS version. In RTEMS the tools are specific to a specific
version because of variations between Newlib and RTEMS. Restructuring in RTEMS
and Newlib sometimes moves *libc* functionality between these two parts and
this makes existing tools incompatible with RTEMS.
RTEMS allows architectures to have different tool versions and patches. The
large number of architectures RTEMS supports can make it difficult to get a
common stable version of all the packages. An architecture may require a recent
GCC because an existing bug has been fixed, however the more recent version may
have a bug in other architecture. Architecture specific patches should be
limited to the architecture it relates to. The patch may fix a problem on the
effect architecture however it could introduce a problem in another
architecture. Limit exposure limits any possible crosstalk between
architectures.
If you are building a released version of RTEMS the release RTEMS tar file will
be downloaded and built as part of the build process. If you are building a
tool set for use with the development branch of RTEMS, the development branch
will be cloned directly from the RTEMS GIT repository and built.
When building RTEMS within the RTEMS Source Builder it needs a suitable working
``autoconf`` and ``automake``. These packages need to built and installed in their
prefix in order for them to work. The RTEMS Source Builder installs all
packages only after they have been built so if you host does not have a
recent enough version of ``autoconf`` and ``automake`` you first need to build them
and install them then build your tool set. The commands are::
$ ../source-builder/sb-set-builder --log=l-4.11-at.txt \
--prefix=$HOME/development/rtems/4.11 4.11/rtems-autotools
$ export PATH=~/development/rtems/4.11/bin:$PATH <1>
$ ../source-builder/sb-set-builder --log=l-4.11-sparc.txt \
--prefix=$HOME/development/rtems/4.11 4.11/rtems-sparc
.. topic:: Items:
1. Setting the path.
If this is your first time building the tools and RTEMS it pays to add the
``--dry-run`` option. This will run through all the configuration files and if
any checks fail you will see this quickly rather than waiting for until the
build fails a check.
To build snapshots for testing purposes you use the available macro maps
passing them on the command line using the ``--macros`` option. For RTEMS these
are held in ``config/snapshots`` directory. The following builds *newlib* from
CVS::
$ ../source-builder/sb-set-builder --log=l-4.11-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
--macros=snapshots/newlib-head.mc \
4.11/rtems-sparc
and the following uses the version control heads for ``binutils``, ``gcc``,
``newlib``, ``gdb`` and *RTEMS*::
$ ../source-builder/sb-set-builder --log=l-heads-sparc.txt \
--prefix=$HOME/development/rtems/4.11-head \
--macros=snapshots/binutils-gcc-newlib-gdb-head.mc \
4.11/rtems-sparc
Patches
~~~~~~~
Packages being built by the RSB need patches from time to time and the RSB
supports patching upstream packages. The patches are held in a seperate
directory called ``patches`` relative to the configuration directory you are
building. For example ``%{_topdir}/patches:%{_sbdir}/patches``. Patches are
declared in the configuration files in a similar manner to the package's source
so please refer to the ``%source`` documentation. Patches, like the source, are
to be made publically available for configurations that live in the RSB package
and are downloaded on demand.
If a package has a patch management tool it is recommended you reference the
package's patch management tools directly. If the RSB does not support the
specific patch manage tool please contact the mailing list to see if support
can be added.
Patches for packages developed by the RTEMS project can be placed in the RTEMS
Tools Git repository. The ``tools`` directory in the repository has various
places a patch can live. The tree is broken down in RTEMS releases and then
tools within that release. If the package is not specific to any release the
patch can be added closer to the top under the package's name. Patches to fix
specific tool related issues for a specific architecture should be grouped
under the specific architecture and only applied when building that
architecture avoiding a patch breaking an uneffected architecture.
Patches in the RTEMS Tools repository need to be submitted to the upstream
project. It should not be a clearing house for patches that will not be
accepted upstream.
Patches are added to a component's name and in the ``%prep:`` section the
patches can be set up, meaning they are applied to source. The patches
are applied in the order they are added. If there is a dependency make
sure you order the patches correctly when you add them. You can add any
number of patches and the RSB will handle them efficently.
Patches can have options. These are added before the patch URL. If no options
are provided the patch's setup default options are used.
Patches can be declared in build set up files.
This examples shows how to declare a patch for gdb in the ``lm32`` architecture::
%patch add <1> gdb <2> %{rtems_gdb_patches}/lm32/gdb-sim-lm32uart.diff <3>
.. topic:: Items:
1. The patch's ``add`` command.
2. The group of patches this patch belongs too.
3. The patch's URL. It is downloaded from here.
Patches require a checksum to avoid a warning. The ``%hash`` directive can be
used to add a checksum for a patch that is used to verify the patch::
%hash md5 <1> gdb-sim-lm32uart.diff <2> 77d070878112783292461bd6e7db17fb <3>
.. topic:: Items:
1. The type of checksum, in the case an MD5 hash.
2. The patch file the checksum is for.
3. The MD5 hash.
The patches are applied when a patch ``setup`` command is issued in the
``%prep:`` section. All patches in the group are applied. To apply the GDB
patch above use::
%patch setup <1> gdb <2> -p1 <3>
.. topic:: Items:
1. The patch's ``setup`` command.
2. The group of patches to apply.
3. The patch group's default options. If no option is given with the patch
these options are used.
Architecture specific patches live in the architecture build set file isolating
the patch to that specific architecture. If a patch is common to a tool it
resides in the RTEMS tools configuration file. Do not place patches for tools
in the ``source-builder/config`` template configuration files.
To test a patch simply copy it to your local ``patches`` directory. The RSB
will see the patch is present and will not attempt to download it. Once you are
happy with the patch submit it to the project and a core developer will review
it and add it to the RTEMS Tools git repository. For example, to test a local
patch for newlib, add the following two lines to the .cfg file in
``rtems/config/tools/`` that is included by the bset you use:
.. code-block:: auto
%patch add newlib file://0001-this-is-a-newlib-patch.patch <1>
%hash md5 0001-this-is-a-newlib-patch.diff 77d070878112783292461bd6e7db17fb <2>
.. topic:: Items:
1. The diff file prepended with ``file://`` to tell RSB this is a local file.
2. The output from md5sum on the diff file.

531
rsb/quick-start.rst Normal file
View File

@ -0,0 +1,531 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
Quick Start
###########
The quick start will show you how to build a set of RTEMS tools for a supported
architecture. The tools are installed into a build *prefix*. The *prefix* is the
top of a group of directories containing all the files needed to develop RTEMS
applications. Building an RTEMS build set will build all that you need. This
includes autoconf, automake, assemblers, linkers, compilers, debuggers,
standard libraries and RTEMS itself.
There is no need to become root or the administrator and we recommend you
avoid doing this. You can build and install the tools anywhere on the
host's file system you, as a standard user, have read and write access
too. I recommend you use your home directory and work under the directory
``~/development/rtems``. The examples shown here will do this.
You can use the build *prefix* to install and maintain different versions of
the tools. Doing this lets you try a new set of tools while not touching your
proven working production set of tools. Once you have proven the new tools are
working rebuild with the *production* prefix switching your development to them.
We recommend you keep your environment to the bare minimum, particularly the
path variable. Using environment variables has been proven over the years to be
difficult to manage in production systems.
.. warning::
The RSB assumes your host is set up and the needed packages are installed
and configured to work. If your host has not been set up please refer to
:ref:`Hosts` and your host's section for packages you need to install.
.. topic:: Path to use when building applications:
Do not forget to set the path before you use the tools, for example to
build the RTEMS kernel.
The RSB by default will install (copy) the executables to a directory tree
under the *prefix* you supply. To use the tools once finished just set your
path to the ``bin`` directory under the *prefix* you use. In the examples
that follow the *prefix* is ``$HOME/development/rtems/4.11`` and is set
using the ``--prefix`` option so the path you need to configure to build
applications can be set with the following in a BASH shell:
.. code-block:: shell
$ export PATH=$HOME/development/rtems/4.11/bin:$PATH
Make sure you place the RTEMS tool path at the front of your path so they
are searched first. RTEMS can provide newer versions of some tools your
operating system provides and placing the RTEMS tools path at the front
means it is searched first and the RTEMS needed versions of the tools are
used.
.. note::
RSB and RTEMS have a matching *git branch* for each version of RTEMS. For
example, if you want to build a toolchain for 4.11, then you should
checkout the 4.11 branch of the RSB:
.. code-block:: shell
$ git checkout -t origin/4.11
Branches are available for the 4.9, 4.10, and 4.11 versions of RTEMS.
Setup
~~~~~
Setup a development work space::
$ cd
$ mkdir -p development/rtems/src
$ cd development/rtems/src
The RTEMS Source Builder is distributed as source. It is Python code so all you
need to do is download the release's RSB tarball or clone the code directly
from the RTEMS GIT repository::
$ git clone git://git.rtems.org/rtems-source-builder.git
$ cd rtems-source-builder
.. topic:: Workspaces
The examples in the *Quick Start Guide* build and install tools in your
*home* directory. Please refer to the RTEMS User Manual for more detail
about *Sandboxing* and the *prefix*.
Checking
~~~~~~~~
The next step is to check if your host is set up correctly. The RTEMS Source
Builder provides a tool to help::
$ source-builder/sb-check
warning: exe: absolute exe found in path: (__objcopy) /usr/local/bin/objcopy <1>
warning: exe: absolute exe found in path: (__objdump) /usr/local/bin/objdump
error: exe: not found: (_xz) /usr/local/bin/xz <2>
RTEMS Source Builder environment is not correctly set up
$ source-builder/sb-check
RTEMS Source Builder environment is ok <3>
.. topic:: Items:
1. A tool is in the environment path but it does not match the expected path.
2. The executable ``xz`` is not found.
3. The host's environment is set up correct.
The checking tool will output a list of executable files not found if problems
are detected. Locate those executable files and install them. You may also be
given a list of warnings about executable files not in the expected location
however the executable was located somewhere in your environment's path. You
will need to check each tool to determine if this is an issue. An executable
not in the standard location may indicate it is not the host operating system's
standard tool. It maybe ok or it could be buggy, only you can determine this.
The :ref:`Hosts` section lists packages you should install for common host
operating systems. It maybe worth checking if you have those installed.
Build Sets
~~~~~~~~~~
The RTEMS tools can be built within the RTEMS Source Builder's source tree. We
recommend you do this so lets change into the RTEMS directory in the RTEMS
Source Builder package::
$ cd rtems
If you are unsure how to specify the build set for the architecture you wish to
build ask the tool::
$ ../source-builder/sb-set-builder --list-bsets <1>
RTEMS Source Builder - Set Builder, v4.11.0
Examining: config
Examining: ../source-builder/config <2>
4.10/rtems-all.bset <3>
4.10/rtems-arm.bset <4>
4.10/rtems-autotools.bset
4.10/rtems-avr.bset
4.10/rtems-bfin.bset
4.10/rtems-h8300.bset
4.10/rtems-i386.bset
4.10/rtems-lm32.bset
4.10/rtems-m32c.bset
4.10/rtems-m32r.bset
4.10/rtems-m68k.bset
4.10/rtems-mips.bset
4.10/rtems-nios2.bset
4.10/rtems-powerpc.bset
4.10/rtems-sh.bset
4.10/rtems-sparc.bset
4.11/rtems-all.bset
4.11/rtems-arm.bset
4.11/rtems-autotools.bset
4.11/rtems-avr.bset
4.11/rtems-bfin.bset
4.11/rtems-h8300.bset
4.11/rtems-i386.bset
4.11/rtems-lm32.bset
4.11/rtems-m32c.bset
4.11/rtems-m32r.bset
4.11/rtems-m68k.bset
4.11/rtems-microblaze.bset
4.11/rtems-mips.bset
4.11/rtems-moxie.bset
4.11/rtems-nios2.bset
4.11/rtems-powerpc.bset
4.11/rtems-sh.bset
4.11/rtems-sparc.bset
4.11/rtems-sparc64.bset
4.11/rtems-v850.bset
4.9/rtems-all.bset
4.9/rtems-arm.bset
4.9/rtems-autotools.bset
4.9/rtems-i386.bset
4.9/rtems-m68k.bset
4.9/rtems-mips.bset
4.9/rtems-powerpc.bset
4.9/rtems-sparc.bset
gnu-tools-4.6.bset
rtems-4.10-base.bset <5>
rtems-4.11-base.bset
rtems-4.9-base.bset
rtems-base.bset <5>
.. topic:: Items:
1. Only option required is ``--list-bsets``
2. The paths inspected. See :ref:`Configuration`.
3. A build set to build all RTEMS 4.10 supported architectures.
4. The build set for the ARM architecture on RTEMS 4.10.
5. Support build set file with common functionality included by other build
set files.
Building
~~~~~~~~
The quick start builds a SPARC tool set::
$ ../source-builder/sb-set-builder --log=l-sparc.txt \ <1>
--prefix=$HOME/development/rtems/4.11 \ <2>
4.11/rtems-sparc <3>
Source Builder - Set Builder, v0.2.0
Build Set: 4.11/rtems-sparc
config: expat-2.1.0-1.cfg <4>
package: expat-2.1.0-x86_64-freebsd9.1-1
building: expat-2.1.0-x86_64-freebsd9.1-1
config: tools/rtems-binutils-2.22-1.cfg <5>
package: sparc-rtems4.11-binutils-2.22-1
building: sparc-rtems4.11-binutils-2.22-1
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg <6>
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
config: tools/rtems-gdb-7.5.1-1.cfg <7>
package: sparc-rtems4.11-gdb-7.5.1-1
building: sparc-rtems4.11-gdb-7.5.1-1
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11 <8>
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
cleaning: expat-2.1.0-x86_64-freebsd9.1-1 <9>
cleaning: sparc-rtems4.11-binutils-2.22-1
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
cleaning: sparc-rtems4.11-gdb-7.5.1-1
Build Set: Time 0:13:43.616383 <10>
.. topic:: Items
1. Providing a log file redirects the build output into a file. Logging the
build output provides a simple way to report problems.
2. The prefix is the location on your file system the tools are installed
into. Provide a prefix to a location you have read and write access. You
can use the prefix to install different versions or builds of tools. Just
use the path to the tools you want to use when building RTEMS.
3. The build set. This is the SPARC build set. First a specifically
referenced file is checked for and if not found the ``%{_configdir}`` path
is searched. The set builder will first look for files with a ``.bset``
extension and then for a configuration file with a ``.cfg`` extension.
4. The SPARC build set first builds the expat library as it is used in GDB.
This is the expat configuration used.
5. The binutils build configuration.
6. The GCC and Newlib build configuration.
7. The GDB build configuration.
8. Installing the built packages to the install prefix.
9. All the packages built are cleaned at the end. If the build fails all the
needed files are present. You may have to clean up by deleting the build
directory if the build fails.
10. The time to build the package. This lets you see how different host
hardware or configurations perform.
Your SPARC RTEMS 4.11 tool set will be installed and ready to build RTEMS and
RTEMS applications. When the build runs you will notice the tool fetch the
source code from the internet. These files are cached in directies called
``source`` and ``patches``. If you run the build again the cached files are
used. This is what happened in the shown example. Archiving these directories
archives the source you need to recreate the build.
.. topic:: RTEMS Releases
The RSB found in a release will automatically build and install RTEMS. If you
do not want a released version of the RSB to build RTEMS add
``--without-rtems`` to the command line. The development version requires
adding ``--with-rtems`` to build RTEMS. Use this option to create a single
command to build the tools and RTEMS.
The source used in release builds is downloaded from the RTEMS FTP
server. This ensures the source is always available for a release.
The installed tools::
$ ls $HOME/development/rtems/4.11
bin include lib libexec share sparc-rtems4.11
$ ls $HOME/development/rtems/4.11/bin
sparc-rtems4.11-addr2line sparc-rtems4.11-cpp
sparc-rtems4.11-gcc-ar sparc-rtems4.11-gprof
sparc-rtems4.11-objdump sparc-rtems4.11-size
sparc-rtems4.11-ar sparc-rtems4.11-elfedit
sparc-rtems4.11-gcc-nm sparc-rtems4.11-ld
sparc-rtems4.11-ranlib sparc-rtems4.11-strings
sparc-rtems4.11-as sparc-rtems4.11-g++
sparc-rtems4.11-gcc-ranlib sparc-rtems4.11-ld.bfd
sparc-rtems4.11-readelf sparc-rtems4.11-strip
sparc-rtems4.11-c++ sparc-rtems4.11-gcc
sparc-rtems4.11-gcov sparc-rtems4.11-nm
sparc-rtems4.11-run xmlwf
sparc-rtems4.11-c++filt sparc-rtems4.11-gcc-4.7.2
sparc-rtems4.11-gdb sparc-rtems4.11-objcopy
sparc-rtems4.11-sis
$ $HOME/development/rtems/4.11/bin/sparc-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=/home/chris/development/rtems/4.11/bin/sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/usr/home/chris/development/rtems/4.11/bin/../ \
libexec/gcc/sparc-rtems4.11/4.7.2/lto-wrapper
Target: sparc-rtems4.11 <1>
Configured with: ../gcc-4.7.2/configure <2>
--prefix=/home/chris/development/rtems/4.11
--bindir=/home/chris/development/rtems/4.11/bin
--exec_prefix=/home/chris/development/rtems/4.11
--includedir=/home/chris/development/rtems/4.11/include
--libdir=/home/chris/development/rtems/4.11/lib
--libexecdir=/home/chris/development/rtems/4.11/libexec
--mandir=/home/chris/development/rtems/4.11/share/man
--infodir=/home/chris/development/rtems/4.11/share/info
--datadir=/home/chris/development/rtems/4.11/share
--build=x86_64-freebsd9.1 --host=x86_64-freebsd9.1 --target=sparc-rtems4.11
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs --disable-lto
--enable-threads --enable-plugin --enable-newlib-io-c99-formats
--enable-newlib-iconv --enable-languages=c,c++
Thread model: rtems <3>
gcc version 4.7.2 20120920 <4>
(RTEMS 4.11 RSB cb12e4875c203f794a5cd4b3de36101ff9a88403)-1 newlib 2.0.0) (GCC)
.. topic:: Items
1. The target the compiler is built for.
2. The configure options used to build GCC.
3. The threading model is always RTEMS. This makes using the RTEMS tools for
bare metal development more difficult.
4. The version string. It contains the Git hash of the RTEMS Source Builder
you are using. If your local clone has been modifed that state is also
recorded in the version string. The hash allows you to track from a GCC
executable back to the original source used to build it.
.. note::
The RTEMS thread model enables specific hooks in GCC so applications built
with RTEMS tools need the RTEMS runtime to operate correctly. You can use
RTEMS tools to build bare metal component but it is more difficult than with
a bare metal tool chain and you need to know what you are doing at a low
level. The RTEMS Source Builder can build bare metal tool chains as
well. Look in the top level ``bare`` directory.
Distributing and Archiving A Build
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you wish to create and distribute your build or you want to archive a build
you can create a tar file. This is a more advanced method for binary packaging
and installing of tools.
By default the RTEMS Source Builder installs the built packages directly and
optionally it can also create a *build set tar file* or a *package tar file*
per package built. The normal and default behaviour is to let the RTEMS Source
Builder install the tools. The source will be downloaded, built, installed and
cleaned up.
The tar files are created with the full build prefix present and if you follow
the examples given in this documentation the path is absolute. This can cause
problems if you are installing on a host you do not have super user or
administrator rights on because the prefix path may references part you do not
have write access too and tar will not extract the files. You can use the
``--strip-components`` option in tar if your host tar application supports it
to remove the parts you do not have write access too or you may need to unpack
the tar file somewhere and copy the file tree from the level you have write
access from. Embedding the full prefix path in the tar files lets you know what
the prefix is and is recommended. For example if
``/home/chris/development/rtems/4.11`` is the prefix used you cannot change
directory to the root (``/``) and install because the ``/home`` is root access
only. To install you would:
.. code-block:: shell
$ cd
$ tar --strip-components=3 -xjf rtems-4.11-sparc-rtems4.11-1.tar.bz2
A build set tar file is created by adding ``--bset-tar-file`` option to the
``sb-set-builder`` command::
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
--bset-tar-file \ <1>
4.11/rtems-sparc
Source Builder - Set Builder, v0.2.0
Build Set: 4.11/rtems-sparc
config: expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-freebsd9.1-1
building: expat-2.1.0-x86_64-freebsd9.1-1
config: tools/rtems-binutils-2.22-1.cfg
package: sparc-rtems4.11-binutils-2.22-1
building: sparc-rtems4.11-binutils-2.22-1
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
config: tools/rtems-gdb-7.5.1-1.cfg
package: sparc-rtems4.11-gdb-7.5.1-1
building: sparc-rtems4.11-gdb-7.5.1-1
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11 <2>
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2 <3>
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
cleaning: sparc-rtems4.11-binutils-2.22-1
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
cleaning: sparc-rtems4.11-gdb-7.5.1-1
Build Set: Time 0:15:25.92873
.. topic:: Items
1. The option to create a build set tar file.
2. The installation still happens unless you specify ``--no-install``.
3. Creating the build set tar file.
You can also suppress installing the files using the ``--no-install``
option. This is useful if your prefix is not accessiable, for example when
building Canadian cross compiled tool sets::
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
--bset-tar-file \
--no-install \ <1>
4.11/rtems-sparc
Source Builder - Set Builder, v0.2.0
Build Set: 4.11/rtems-sparc
config: expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-freebsd9.1-1
building: expat-2.1.0-x86_64-freebsd9.1-1
config: tools/rtems-binutils-2.22-1.cfg
package: sparc-rtems4.11-binutils-2.22-1
building: sparc-rtems4.11-binutils-2.22-1
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
config: tools/rtems-gdb-7.5.1-1.cfg
package: sparc-rtems4.11-gdb-7.5.1-1
building: sparc-rtems4.11-gdb-7.5.1-1
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2 <2>
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
cleaning: sparc-rtems4.11-binutils-2.22-1
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
cleaning: sparc-rtems4.11-gdb-7.5.1-1
Build Set: Time 0:14:11.721274
$ ls tar
rtems-4.11-sparc-rtems4.11-1.tar.bz2
.. topic:: Items
1. The option to supressing installing the packages.
2. Create the build set tar.
A package tar file can be created by adding the ``--pkg-tar-files`` to the
``sb-set-builder`` command. This creates a tar file per package built in the
build set::
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
--prefix=$HOME/development/rtems/4.11 \
--bset-tar-file \
--pkg-tar-files \ <1>
--no-install 4.11/rtems-sparc
Source Builder - Set Builder, v0.2.0
Build Set: 4.11/rtems-sparc
config: expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-freebsd9.1-1
building: expat-2.1.0-x86_64-freebsd9.1-1
config: tools/rtems-binutils-2.22-1.cfg
package: sparc-rtems4.11-binutils-2.22-1
building: sparc-rtems4.11-binutils-2.22-1
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
config: tools/rtems-gdb-7.5.1-1.cfg
package: sparc-rtems4.11-gdb-7.5.1-1
building: sparc-rtems4.11-gdb-7.5.1-1
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
cleaning: sparc-rtems4.11-binutils-2.22-1
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
cleaning: sparc-rtems4.11-gdb-7.5.1-1
Build Set: Time 0:14:37.658460
$ ls tar
expat-2.1.0-x86_64-freebsd9.1-1.tar.bz2 sparc-rtems4.11-binutils-2.22-1.tar.bz2
sparc-rtems4.11-gdb-7.5.1-1.tar.bz2 <2> rtems-4.11-sparc-rtems4.11-1.tar.bz2 <3>
sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1.tar.bz2
.. topic:: Items
1. The option to create packages tar files.
2. The GDB package tar file.
3. The build set tar file. All the others in a single tar file.
Controlling the Build
~~~~~~~~~~~~~~~~~~~~~
Build sets can be controlled via the command line to enable and disable various
features. There is no definitive list of build options that can be listed
because they are implemented with the configuration scripts. The best way to
find what is available is to grep the configuration files. for ``with`` and
``without``.
Following are currentlt available:
``--without-rtems``
Do not build RTEMS when building an RTEMS build set.
``--without-cxx``
Do not build a C++ compiler.
``--with-objc``
Attempt to build a C++ compiler.
``--with-fortran``
Attempt to build a Fortran compiler.

3564
rsb/source-builder.rst
View File

File diff suppressed because it is too large Load Diff

314
rsb/third-party-packages.rst Normal file
View File

@ -0,0 +1,314 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
.. comment COPYRIGHT (c) 2012 - 2016.
.. comment Chris Johns <chrisj@rtems.org>
RTEMS 3rd Party Packages
########################
This section describes how to build and add an RTEMS 3rd party package to the
RSB.
A 3rd party package is a library or software package built to run on RTEMS,
examples are NTP, Net-Snmp, libjpeg or Python. These pieces of software can be
used to help build RTEMS applications. The package is built for a specific
BSP and so requires a working RTEMS tool chain and an installed RTEMS Board
Support Package (BSP).
The RSB support for building 3rd party packages is based around the *pkconfig*
files (PC) installed with the BSP. The pkgconfig support in RTEMS is considered
experimental and can have some issues for some BSPs. This issue is rooted deep
in the RTEMS build system. If you have any issues with this support please ask
on the RTEMS developers mailing list.
Vertical Integration
~~~~~~~~~~~~~~~~~~~~
The RSB supports horizontal integration with support for multiple
architectures. Adding packages to the RSB as libraries is vertical
integration. Building the GCC tool chain requires you build an assembler before
you build a compiler. The same can be done for 3rd party libraries, you can
crate build sets that stack library dependences vertically to create a *stack*.
Building
~~~~~~~~
To build a package you need to have a suitable RTEMS tool chain and RTEMS BSP
installed. The set builder command line requires you provide the tools path,
the RTEMS host, and the prefix path to the installed RTEMS BSP. The prefix
needs to be the same as the prefix used to build RTEMS.
To build Net-SNMP the command is:
.. code-block:: shell
$ cd rtems-source-builder/rtems
$ ../source-builder/sb-set-builder --log=log_sis_net_snmp \
--prefix=$HOME/development/rtems/bsps/4.11 \
--with-tools=$HOME/development/rtems/4.11 \
--host=sparc-rtems4.11 --with-rtems-bsp=sis 4.11/net-mgmt/net-snmp
RTEMS Source Builder - Set Builder, v0.3.0
Build Set: 4.11/net-mgmt/net-snmp
config: net-mgmt/net-snmp-5.7.2.1-1.cfg
package: net-snmp-5.7.2.1-sparc-rtems4.11-1
building: net-snmp-5.7.2.1-sparc-rtems4.11-1
installing: net-snmp-5.7.2.1-sparc-rtems4.11-1 -> /Users/chris/development/rtems/bsps/4.11
cleaning: net-snmp-5.7.2.1-sparc-rtems4.11-1
Build Set: Time 0:01:10.651926
Adding
~~~~~~
Adding a package requires you first build it manually by downloading the source
for the package and building it for RTEMS using the command line of a standard
shell. If the package has not been ported to RTEMS you will need to port it and
this may require you asking questions on the package's user or development
support lists as well as RTEMS's developers list. Your porting effort may end
up with a patch. RTEMS requires a patch be submitted upstream to the project's
community as well as RTEMS so it can be added to the RTEMS Tools git
repository. A patch in the RTEMS Tools git reposiitory can then be referenced
by an RSB configuration file.
A package may create executables, for example NTP normally creates executables
such as ``ntdp``, ``ntpupdate``, or ``ntpdc``. These executables can be useful
when testing the package however they are of limited use by RTEMS users because
they cannot be directly linked into a user application. Users need to link to
the functions in these executables or even the executable as a function placed
in libraries. If the package does not export the code in a suitable manner
please contact the project's commuinity and see if you can work them to provide
a way for the code to be exported. This may be difficult because exporting
internal headers and functions opens the project up to API compatibility issues
they did not have before. In the simplest case attempting to get the code into
a static library with a single call entry point exported in a header would give
RTEMS user's access to the package's main functionality.
A package requires 3 files to be created:
- The first file is the RTEMS build set file and it resides in the
``rtems/config/%{rtems_version}`` path in a directory tree based on the
FreeBSD ports collection. For the NTP package and RTEMS 4.11 this is
``rtems/config/4.11/net/ntp.bset``. If you do not know the FreeBSD port path
for the package you are adding please ask. The build set file references a
specific configuration file therefore linking the RTEMS version to a specific
version of the package you are adding. Updating the package to a new version
requires changing the build set to the new configuration file.
- The second file is an RTEMS version specific configuration file and it
includes the RSB RTEMS BSP support. These configuration files reside in the
``rtems/config`` tree again under the FreeBSD port's path name. For example
the NTP package is found in the ``net`` directory of the FreeBSD ports tree
so the NTP configuration path is ``rtems/config/net/ntp-4.2.6p5-1.cfg`` for
that specific version. The configuration file name typically provides version
specific references and the RTEMS build set file references a specific
version. This configuration file references the build configuration file held
in the common configuration file tree.
- The build configuration. This is a common script that builds the package. It
resides in the ``source-builder/config`` directory and typically has the
packages's name with the major version number. If the build script does not
change for each major version number a *common* base script can be created
and included by each major version configuration script. The *gcc* compiler
configuration is an example. This approach lets you branch a version if
something changes that is not backwards compatible. It is important to keep
existing versions building. The build configuration should be able to build a
package for the build host as well as RTEMS as the RSB abstracts the RTEMS
specific parts. See :ref:`Configuration` for more details.
BSP Support
~~~~~~~~~~~
The RSB provides support to help build packages for RTEMS. RTEMS applications
can be viewed as statically linked executables operating in a single address
space. As a result only the static libraries a package builds are required and
these libraries need to be ABI compatible with the RTEMS kernel and application
code meaning compiler ABI flags cannot be mixed when building code. The 3rd
party package need to use the same compiler flags as the BSP used to build
RTEMS.
.. note::
RTEMS's dynamic loading support does not use the standard shared library
support found in Unix and the ELF standard. RTEMS's loader uses static
libraries and the runtime link editor performs a similar function to a host
based static linker. RTEMS will only reference static libraries even if
dynamic libraries are created and installed.
The RSB provides the configuration file ``rtems/config/rtems-bsp.cfg`` to
support building 3rd party packages and you need to include this file in your
RTEMS version specific configuration file. For example the Net-SNMP
configuration file ``rtems/config/net-mgmt/net-snmp-5.7.2.1-1.cfg``::
#
# NetSNMP 5.7.2.1
#
%if %{release} == %{nil}
%define release 1 <1>
%endif
%include %{_configdir}/rtems-bsp.cfg <2>
#
# NetSNMP Version
#
%define net_snmp_version 5.7.2.1 <3>
#
# We need some special flags to build this version.
#
%define net_snmp_cflags <4> -DNETSNMP_CAN_USE_SYSCTL=1 -DARP_SCAN_FOUR_ARGUMENTS=1 -DINP_IPV6=0
#
# Patch for RTEMS support.
#
%patch add net-snmp %{rtems_git_tools}/net-snmp/rtems-net-snmp-5.7.2.1-20140623.patch <5>
#
# NetSNMP Build configuration
#
%include %{_configdir}/net-snmp-5-1.cfg <6>
.. topic:: Items:
1. The release number.
2. Include the RSB RTEMS BSP support.
3. The Net-SNMP package's version.
4. Add specific CFLAGS to the build process. See the
``net-snmp-5.7.2.1-1.cfg`` for details.
5. The RTEMS Net-SNMP patch downloaded from the RTEMS Tools git repo.
6. The Net-SNMP standard build configuration.
The RSB RTEMS BSP support file ``rtems/config/rtems-bsp.cfg`` checks to make
sure standard command line options are provided. These include ``--host`` and
``--with-rtems-bsp``. If the ``--with-tools`` command line option is not given
the ``${_prefix}`` is used::
%if %{_host} == %{nil} <1>
%error No RTEMS target specified: --host=host
%endif
%ifn %{defined with_rtems_bsp} <2>
%error No RTEMS BSP specified: --with-rtems-bsp=bsp
%endif
%ifn %{defined with_tools} <3>
%define with_tools %{_prefix}
%endif
#
# Set the path to the tools.
#
%{path prepend %{with_tools}/bin} <4>
.. topic:: Items:
1. Check the host has been set.
2. Check a BSP has been specified.
3. If no tools path has been provided assume they are under the
``%{_prefix}``.
4. Add the tools ``bin`` path to the system path.
RTEMS exports the build flags used in *pkgconfig* (.pc) files and the RSB can
read and manage them even when there is no pkgconfig support installed on your
build machine. Using this support we can obtain a BSP's configuration and set
some standard macros variables (``rtems/config/rtems-bsp.cfg``)::
%{pkgconfig prefix %{_prefix}/lib/pkgconfig} <1>
%{pkgconfig crosscompile yes} <2>
%{pkgconfig filter-flags yes} <3>
#
# The RTEMS BSP Flags
#
%define rtems_bsp %{with_rtems_bsp}
%define rtems_bsp_ccflags %{pkgconfig ccflags %{_host}-%{rtems_bsp}} <4>
%define rtems_bsp_cflags %{pkgconfig cflags %{_host}-%{rtems_bsp}}
%define rtems_bsp_ldflags %{pkgconfig ldflags %{_host}-%{rtems_bsp}}
%define rtems_bsp_libs %{pkgconfig libs %{_host}-%{rtems_bsp}}
.. topic:: Items:
1. Set the path to the BSP's pkgconfig file.
2. Let pkgconfig know this is a cross-compile build.
3. Filter flags such as warnings. Warning flags are specific to a package.
4. Ask pkgconfig for the various items we require.
The flags obtain by pkgconfig and given a ``rtems_bsp_`` prefix and we uses these
to set the RSB host support CFLAGS, LDFLAGS and LIBS flags. When we build a 3rd
party library your host computer is the _build_ machine and RTEMS is the _host_
machine therefore we set the ``host`` variables
(``rtems/config/rtems-bsp.cfg``)::
%define host_cflags %{rtems_bsp_cflags}
%define host_ldflags %{rtems_bsp_ldflags}
%define host_libs %{rtems_bsp_libs}
Finally we provide all the paths you may require when configuring a
package. Packages by default consider the ``_prefix`` the base and install
various files under this tree. The package you are building is specific to a
BSP and so needs to install into the specific BSP path under the
``_prefix``. This allows more than BSP build of this package to be install
under the same ``_prefix`` at the same time (``rtems/config/rtems-bsp.cfg``)::
%define rtems_bsp_prefix %{_prefix}/%{_host}/%{rtems_bsp} <1>
%define _exec_prefix %{rtems_bsp_prefix}
%define _bindir %{_exec_prefix}/bin
%define _sbindir %{_exec_prefix}/sbin
%define _libexecdir %{_exec_prefix}/libexec
%define _datarootdir %{_exec_prefix}/share
%define _datadir %{_datarootdir}
%define _sysconfdir %{_exec_prefix}/etc
%define _sharedstatedir %{_exec_prefix}/com
%define _localstatedir %{_exec_prefix}/var
%define _includedir %{_libdir}/include
%define _lib lib
%define _libdir %{_exec_prefix}/%{_lib}
%define _libexecdir %{_exec_prefix}/libexec
%define _mandir %{_datarootdir}/man
%define _infodir %{_datarootdir}/info
%define _localedir %{_datarootdir}/locale
%define _localedir %{_datadir}/locale
%define _localstatedir %{_exec_prefix}/var
.. topic:: Items:
1. The path to the BSP.
When you configure a package you can reference these paths and the RSB will
provide sensible default or in this case map them to the BSP
(``source-builder/config/ntp-4-1.cfg``)::
../${source_dir_ntp}/configure \ <1>
--host=%{_host} \
--prefix=%{_prefix} \
--bindir=%{_bindir} \
--exec_prefix=%{_exec_prefix} \
--includedir=%{_includedir} \
--libdir=%{_libdir} \
--libexecdir=%{_libexecdir} \
--mandir=%{_mandir} \
--infodir=%{_infodir} \
--datadir=%{_datadir} \
--disable-ipv6 \
--disable-HOPFPCI
.. topic:: Items:
1. The configure command for NTP.
RTEMS BSP Configuration
~~~~~~~~~~~~~~~~~~~~~~~
To build a package for RTEMS you need to build it with the matching BSP
configuration. A BSP can be built with specific flags that require all code
being used needs to be built with the same flags.