 Welcome to the FACE CTS Learning Series, Chapter 3, the CTS User Interface, Video 3, Toolchain Configuration. In this video, we will explain the options contained in the Toolchain Configuration Builder. You may open the Toolchain Configuration Builder by launching the CTS and selecting File, Toolchains, then select New to create a new Toolchain Configuration File. As mentioned in previous videos, the Toolchain Configuration File allows the CTS to interpret and target environments for the UOC to be tested against. The options used to configure the Toolchain are contained in the General, File Extensions, Tools, Compiler Specific, and Notes sections. The General tab first lists the operating system that the Toolchain is targeting. Then, we may select the language the environment will be targeting. Selecting this menu will show options for C, C++, ADA, or Java. Then, we may select what type of segment will be under test. For more information about what these segments are and how to create them, please refer to the FACE Technical Standard and Supporting Documentation. We may select from the Input Output Services segment, Portable Component segment, Platform Specific Services segment, Transport Services segment, Operating Systems segment, Lifecycle Management, or OSS Non-Configuration, Lifecycle Management. To clarify, the latter option provides a means for testing a configuration services and or Lifecycle Management UOC that is tied to an OSS UOC. The former provides a means for testing all other types of UOCs. This is necessary because the testing process is slightly different for testing a configuration services and Lifecycle Management UOC. Then, we must select what kind of operating system segment profile the UOC in question should adhere to. An OSS profile is how the FACE Technical Standard defines and restricts APIs, programming languages, and programming language features, runtimes, frameworks, and graphics capabilities to meet differing levels of criticality. There are three FACE OSS profiles, security, safety, and general, with general being the least restrictive and security being the most restrictive. The safety profile is further broken down into safety base and safety extended. For more information about OSS profiles, please refer to the FACE Technical Standard. The path addition is a mechanism to add global path environment variables when testing a UOC for conformance. Similarly, it is possible to define environment variables for use in the tool chain. The File Extensions tab lets the user define what file types are to be found by the CTS when testing UOCs. For example, for a UOC in C++, a header file extension would be HPP, and a source file extension would be CPP. The Tools tab allows for the user to define the tools necessary to compile, link, and archive for the target environment. This, in turn, allows the CTS to generate the correct commands for the target environment, and thus test the UOC properly. The Compiler section has fields to define the target executable, any flags that might be necessary for execution, an output flag, and any paths that might be necessary to include for successful compilation. The Linker section also defines an executable field, a field to define flags for the linker, an output flag field, and any library paths needed to successfully complete linking. Similarly, the Archiver section defines an executable field, a flags field, and an output flags field. To test the commands that will be generated, the final section allows for the user to supply a toolchain template. The toolchain template is a template for the commands that the CTS will generate when testing the candidate UOC. The CTS supplies common toolchain template files at the installation directory of your conformance test suite, data files, string template. You may open the STG, or string template file, in any text editor. The syntax is based on documentation for Java templates from string templates.org. Going back to the CTS, if we click on the refresh button next to template output, we will see how the CTS plans to interpret our supplied compiler, linker, and archiver executable and flags with a demonstration in the fields contained within that section. A complete example toolchain configuration demonstration will be shown in chapter five. To properly interpret the UOC in the desired compiler, the toolchain configuration builder allows the user to define compiler-specific options. The exact types definitions allows the user to supply what types are defined to your compiler, operating system, and architecture. The CTS interprets special type def types as defined in the conformance test face exact types file. These type sizes are defined by the target compiler, operating system, and architecture. Because of this, type sizes may differ based on the needed compiler, operating system, and architecture, and the documentation for the target environment should be consulted. For example, in GCC, which is a part of the GNU collection of compilers, they have defined an int8 type as a signed char. Next, the target compiler may define no differently. In this section, the CTS allows the user to define a preprocessor directive for the custom implementation of no if necessary. For example, C++ defines no as zero, but C defines no as shown on the screen. The CTS allows for custom allowed definitions to be written by the user as well. These allowed definitions exist to support any function used outside the OSS boundaries to compile properly. By default, an allowed definition must define an entry point. For example, if the tool chain is intended for an iOSS, the user must define device driver calls as an allowed definition. Another example would be if there are compiler specific built-in functions that cause linger errors, even when compiling against the OSGSL. To write an allowed definition, the user must provide a function stub and a simple function body. The eventual objects from the allowed definitions that are created in the conformance test process are never executed. As mentioned in chapter one, the objects are merely linked. If a function that is used in a UOC is defined as an allowed definition, saying it is not necessarily defined by the phase technical standard, and is called, the CTS ignores that function called in that allowed definition in the conformance test. For that reason, a verification authority must verify if the allowed definitions honor the phase profiled as defined in the phase technical standard in order for that UOC to become fully conformant. Finally, there may be graphics related calls that are not specifically defined in the phase technical standard. If the UOC is using a graphical component, the user must utilize the OpenGL definition section. Then the user must select what versions of OpenGL they are using, OpenGL for embedded systems, or ES 2.0, OpenGL for safety critical, or SC applications, or OpenGL for safety critical applications 2.0. The subsequent options allow the user to define paths to header files that are compiler specific to the implementation of OpenGL. Each of these headers define specific function declarations and type definitions for the CTS's use for testing graphical user interfaces within the target UOC. The EGL header file defines an interface between the rendering APIs such as OpenGL ES and the underlying native platform window system. The GL2 header file defines a GL2 interface that contains all core desktop OpenGL methods through OpenGL version 3.0. Last, all OpenGL headers depend on the shared khrplatform.h file. The toolchain configuration builder supplies a section for the user to write any notes necessary for the development and usage of the toolchain. The notes will be shown in the toolchain files list to describe the toolchain configuration file. After configuring the toolchain, we can check the configuration by selecting the check configuration button at the top left of the interface. If there are errors, clicking on the bottom right button will show you details of the errors. Thank you for watching. This concludes the tour of the toolchain configuration builder. In this video, we explained the configuration options in the toolchain configuration builder. In the next video, we will explain the configuration options in the project configuration builder. In subsequent chapters, we will demonstrate the creation of and validation of a new toolchain configuration file on CentOS 7.