[PATCH 2/2] user: Use capital letters for acronyms

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Jan 23 09:42:19 UTC 2019


Fix GCC definition.
---
 user/rsb/index.rst                 | 4 ++--
 user/rsb/why-build-from-source.rst | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

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
-- 
2.16.4




More information about the devel mailing list