From 3db6371539e89ade2c992ee33297716d629ab35e Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Wed, 23 Jan 2019 10:35:50 +0100 Subject: user: Use capital letters for acronyms Fix GCC definition. --- user/rsb/index.rst | 4 ++-- user/rsb/why-build-from-source.rst | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-) (limited to 'user') diff --git a/user/rsb/index.rst b/user/rsb/index.rst index 1f64b51..70f578e 100644 --- a/user/rsb/index.rst +++ b/user/rsb/index.rst @@ -23,7 +23,7 @@ used outside of the RTEMS project and we welcome this. The RTEMS Source Builder is typically used to build a set of tools or a **build set**. A **build set** is a collection of packages and a package is a specific -tool, for example gcc or gdb, or library. The RTEMS Source Builder attempts to +tool, for example GCC or GDB, or library. The RTEMS Source Builder attempts to support any host environment that runs Python and you can build the package on. The RSB is not some sort of magic that can take any piece of source code and make it build. Someone at some point in time has figured out how to build @@ -50,7 +50,7 @@ The RTEMS Source Builder has been tested on: The RTEMS Source Builder has two types of configuration data. The first is the *build set*. A *build set* describes a collection of packages that define a set of tools you would use when developing software for RTEMS. For example the -basic GNU tool set is binutils, gcc, and gdb and is the typical base suite of +basic GNU tool set is Binutils, GCC, and GDB and is the typical base suite of tools you need for an embedded cross-development type project. The second type of configuration data is the configuration files and they define how a package is built. Configuration files are scripts loosely based on the RPM spec file diff --git a/user/rsb/why-build-from-source.rst b/user/rsb/why-build-from-source.rst index 5d88e0c..eefeade 100644 --- a/user/rsb/why-build-from-source.rst +++ b/user/rsb/why-build-from-source.rst @@ -33,8 +33,9 @@ an equivalent tool set. Building from source provides you with control over the configuration of the package you are building. If all or the most important dependent parts are built from source you limit the exposure to host variations. For example the -GNU C compiler (gcc) currently uses a number of third-party libraries internally -(gmp, mpfr, etc). If your validated compiler generating code for your target +GNU Compiler Collection (GCC) currently uses a number of third-party libraries +internally (GMP, ISL, MPC, MPFR, etc.). If your validated compiler generating +code for your target processor is dynamically linked against the host's version of these libraries any change in the host's configuration may effect you. The changes the host's package management system makes may be perfectly reasonable in relation to the -- cgit v1.2.3