set links and fix spell findings

Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>

CONTRIBUTING.md

@@ -127,7 +127,8 @@ All new code should follow the folder structure.
 We use [Google test](https://github.com/google/googletest) for our unit and integration tests. We require compatibility
 with the version 1.8.1.
 
-Have a look at our [best practice guidelines](./doc/website/advanced/best-practice-for-testing.md) for writing tests in iceoryx.
+Have a look at our [best practice guidelines](./doc/website/advanced/best-practice-for-testing.md) for writing tests and
+[Installation guide for contributors](./doc/website/advanced/installation-guide-for-contributors.md#build-and-run-tests) for building them.
 
 ### Unit tests (aka module tests)
 

doc/website/advanced/configuration-guide.md

@@ -18,7 +18,7 @@ These options adjust the limits of Publisher and Subscriber Ports for the resour
 Have a look at [iceoryx_posh_deployment.cmake](https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_posh/cmake/iceoryx_posh_deployment.cmake) for the default values of the constants.
 
 !!! hint
-    With the default values set, the size of `iceoryx_mgmt` is ~64.5 MByte. You can reduce the size by decreasing the values from the table via the CMake options. The current set values are printed in the CMake stage when building iceoryx.
+    With the default values set, the size of `iceoryx_mgmt` is ~64.5 MByte. You can reduce the size by decreasing the values from the table via the CMake options. The current values are printed in the CMake stage when building iceoryx.
 
 Example:
 
@@ -48,9 +48,8 @@ The value for the alignment is set to 32.
 One way is to read a configuration dynamically at RouDi runtime (startup).
 Using TOML Config in RouDi is not mandatory for configuring segments and mempools, but a comfortable alternative.
 
-RouDi can optionally be build with support to read the mempool config from a configuration file.
-To build the feature in iceoryx, the cmake option `-DTOML_CONFIG=ON` must be used.
-The `iox-roudi` build by iceoryx is with TOML support and can be used out of the box.
+To enable the TOML config in iceoryx, the CMake option `-DTOML_CONFIG=ON` must be used (enabled by default).
+The `iox-roudi` provided by iceoryx is with TOML support and can be used out of the box.
 
 If you create your own RouDi application you need to link against `iceoryx_posh_config`:
 

doc/website/advanced/installation-guide-for-contributors.md

@@ -2,20 +2,20 @@
 
 ## Build and run tests
 
-While developing on iceoryx you want to know if your changes are breaking existing functions or if your newly written googletests are passing.
-For that purpose we are generating CMake targets which are executing the tests. But first we need to build them:
+While developing on iceoryx you want to know if your changes are breaking existing functions or if your newly written tests are passing.
+For that purpose we are generating CMake targets which are executing the tests. First we need to build them:
 
 ```bash
 cmake -Bbuild -Hiceoryx_meta -DBUILD_TEST=ON
 cmake --build build
 ```
 
-CMake is automatically installing GoogleTest as dependency and build the tests against it. Please note that if you want to build tests for extensions like the DDS-Gateway you need to enable that as well in the CMake build. To build all tests simply add `-DBUILD_ALL` to the CMake command
+CMake is automatically installing GoogleTest as local dependency and build the tests against it. Please note that if you want to build tests for extensions like the DDS-Gateway you need to enable this extension as well in the CMake build. To build tests for all extensions simply add `-DBUILD_ALL` to the CMake command.
 
 !!! hint
     Before creating a Pull-Request, you should check your code for compiler warnings. For that purpose is the `-DBUILD_STRICT` CMake option available which treats compiler warnings as errors. This flag is enabled on the GitHub CI for building Pull-Requests.
 
-Now lets execute the all tests:
+Now let's execute the all tests:
 
 ```bash
 cd iceoryx/build
@@ -29,15 +29,15 @@ make timing_module_tests
 make timing_integration_tests
 ```
 
-In iceoryx we distinguish between different testlevels. The most important are: Moduletests and Integrationtests.
-Moduletests are basically Unit-tests where the focus is on class level with black-box testing.
-In Integrationtests are multiple classes within one component (e.g. mepoo config) tested together.
-The sourcecode of the tests is placed into the folder `test` within the different iceoryx components. You can find there at least a folder `moduletests` and sometimes `integrationtests`.
+In iceoryx we distinguish between different test levels. The most important are: Module tests and Integration tests.
+Module tests are basically Unit-tests where the focus is on class level with black-box testing.
+In integration tests multiple classes (e.g. mepoo config) are tested together.
+The source code of the tests is placed into the folder `test` within the different iceoryx components. You can find there at least a folder `moduletests` and sometimes `integrationtests`.
 
 If you now want to create a new test you can place the sourcefile directly into the right folder. CMake will automatically detect the new file when doing a clean build and will add it to a executable. There is no need to add a gtest main function because we already provide it.
 For every test level are executables created, for example `posh_moduletests`. They are placed into the corresponding build folder (e.g. `iceoryx/build/posh/test/posh_moduletests`).
 
-If you want to execute only individual testcases then you can use these executables and a gtest filter. Let's assume you want to execute only the `ServiceDescription_test` from the posh_moduletests, then you can do the following:
+If you want to execute only individual testcases then you can use these executables together with a gtest filter. Let's assume you want to execute only the `ServiceDescription_test` from the posh_moduletests, then you can do the following:
 
 ```bash
 ./build/posh/test/posh_moduletests --gtest_filter="ServiceDescription_test*"
@@ -48,7 +48,7 @@ If you want to execute only individual testcases then you can use these executab
 Due to the fact that iceoryx works a lot with system memory it should be ensured that errors like memory leaks are not introduced.
 To prevent these, we use the clang toolchain which offers several tools for scanning the codebase. One of them is the [Address-Sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html) which checks for example on dangling pointers.
 
-In iceoryx below sanitizers are enabled at the moment.
+The below listed sanitizers are enabled at the moment.
 
 - [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)
 AddressSanitizer is a fast memory error detector.
@@ -59,14 +59,14 @@ LeakSanitizer is a run-time memory leak detector. In iceoryx , it runs as part o
 - [UndefinedBehaviorSanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)
 UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector. iceoryx uses default behavior ie `print a verbose error report and continue execution`
 
-In iceoryx are scripts available to do the scan on your own. Additionally the Scans are running on the CI in every Pull-Request.
-As Requirement you should install the clang compiler:
+With the `iceoryx_build_test.sh` script you can do the scan on your own. Additionally the scans are running on the CI in every Pull-Request.
+As a prerequisite you need to install the clang compiler:
 
 ```bash
 sudo apt install clang
 ```
 
-Then you need to compile the iceoryx with the sanitizer flags:
+Then you need to compile iceoryx with the sanitizer flags:
 
 ```bash
 ./tools/iceoryx_build_test.sh build-strict build-all sanitize clang clean
@@ -110,7 +110,7 @@ or you can set it directly:
 LD_LIBRARY_PATH=/your/path/to/lib iox-roudi
 ```
 
-If you want to share iceoryx to other users, you can also create a debian package. You can create it by calling: `./tools/iceoryx_build_test.sh package` where it will be build it in `build_package`.
+If you want to share iceoryx to other users, you can also create a debian package. You can create it by calling: `./tools/iceoryx_build_test.sh package` where it will be deployed into the `build_package` folder.
 
 !!! note
     The CMake libraries exports their dependencies for easier integration. This means that you do not need to do a `findpackage()` to all the dependencies. For example, you don't need to call `findpackage(iceoryx_utils)` when you have it done for iceoryx_posh. It includes it already.

doc/website/getting-started/installation.md

@@ -17,8 +17,8 @@ All iceoryx libraries are deployed as independent CMake packages. Posh is using
 
 #### Optional, Cyclone DDS Gateway
 
-The Cyclone DDS Gateway depends currently on [Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds).
-When building it with the CMake option: `-DDDS_GATEWAY=ON` it will be automatically installed as dependency.
+The Cyclone DDS gateway depends currently on [Cyclone DDS](https://github.com/eclipse-cyclonedds/cyclonedds).
+When building it with the CMake option `-DDDS_GATEWAY=ON` it will be automatically installed as dependency.
 Furthermore you have to install:
 
 - [Apache Maven](http://maven.apache.org/download.cgi), 3.5 or later
@@ -90,7 +90,7 @@ The `CMakeLists.txt` from `iceoryx_meta` can be used to easily develop iceoryx w
 
 1. Clone the repository
 
-    ```sh
+    ```bash
     git clone https://github.com/eclipse-iceoryx/iceoryx.git
     ```
 
@@ -140,12 +140,14 @@ The `CMakeLists.txt` from `iceoryx_meta` can be used to easily develop iceoryx w
 
 ### Build options
 
-Please take a look at the CMake file [build_options.cmake](https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_meta/build_options.cmake) to get an overview of the available build options for enabling additional features.
+Please take a look at the CMake file [build_options.cmake](https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_meta/build_options.cmake)
+to get an overview of the available build options for enabling additional features.
 
 ## Build with script
 
 As an alternative we provide a build-test script which we use to integrate iceoryx into our infrastructure.
-The intention of the script is more than just building with iceoryx, it is also used for the code coverage scan or the address-sanitizer runs on the CI. The script currently only works for Linux and QNX, it is planned to offer a multi-platform solution.
+The intention of the script goes beyond building iceoryx, it is also used for the code coverage scan or the address-sanitizer runs on the CI.
+The script currently works for Linux and QNX only, it is planned to offer a multi-platform solution.
 
  1. Clone the repository
 
@@ -163,7 +165,7 @@ The intention of the script is more than just building with iceoryx, it is also
     !!! note
         The build script is installing the header files and binaries into `build/install/prefix`.
 
-You can use the help for getting an overview over the available options:
+You can use the `help` argument for getting an overview over the available options:
 
 ```bash
 ./tools/iceoryx_build_test.sh help

tools/toolchains/qnx/qnx_sdp70_common.cmake

@@ -51,10 +51,10 @@ SET(CMAKE_OBJDUMP "${QNX_HOST}/usr/bin/nto${CMAKE_SYSTEM_PROCESSOR}-objdump" CAC
 SET(CMAKE_RANLIB  "${QNX_HOST}/usr/bin/nto${CMAKE_SYSTEM_PROCESSOR}-ranlib" CACHE PATH "ranlib")
 
 SET(CMAKE_C_FLAGS_DEBUG "-g -O0 -fno-builtin")
-SET(CMAKE_C_FLAGS_RELEASE "-O2 -DNDEBUG")
+SET(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG")
 
 SET(CMAKE_CXX_FLAGS_DEBUG "-g -O0 -fno-builtin")
-SET(CMAKE_CXX_FLAGS_RELEASE "-O2 -DNDEBUG")
+SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG")
 
 SET(CMAKE_FIND_ROOT_PATH ${QNX_TARGET})
 SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)