 Welcome to the CTS Learning Series, Chapter 5, testing a non-OSS UOC example. Video 2, demonstration of the construction of a non-OSS toolchain. In this video, we will demonstrate the complete construction of a non-OSS toolchain and validate the constructed toolchain. In Chapter 3, we introduce that we will be demonstrating all subsequent videos in CentOS 7. This is important to note, especially for this chapter, as the way some applications are invoked, such as the compiler, may be vastly different due to operating system. All of the demonstrations may be successfully executed on the Windows 10 distribution of the CTS as well, but there may be some variance. In Chapter 3, Video 2, we introduce the overall CTS testing workflow, which began with the construction and validation of the toolchain configuration file. Let's accomplish this step by opening the toolchain files list and clicking on New to create a new toolchain configuration file. The toolchain configuration builder is now shown. For a detailed explanation on the possible options contained in the toolchain configuration builder and what they mean, please refer to Chapter 3, Video 3. Let's save the toolchain immediately, so we don't lose progress as we're configuring the toolchain. Let's name it CTS Learning Series Toolchain Demonstration. Click Save it in the CTS's default directory of your root directory of the CTS slash toolchain slash configuration files. If you recall, this is the toolchain files directory that was defined in the toolchain files list. Click on Save to save the toolchain. Then, we can select the language our UoC is to target. The Balsa UoCs are written in C++. Both the analysis of Balsa UoCs and the development of a face UoC is out of scope for this video series, but more information can be obtained in the Face Technical Standard Reference Implementation Guide, or RIG, and the Software Suppliers Getting Started Guide. Let's set the language to C++. Since we are testing a series of non-OSS UoCs in this chapter, let's select the iOSS, PCS, P3S, TSS, OSS config slash LCM option for our toolchain. The OSS profile that Balsa targets is safety base. Let's select that as well. Our path additions will be slash user slash bin. This is the directory that contains executable files in Unix-like systems, like CentOS. We don't need to supply any environment variables, as our toolchain will not use any executables outside of the user bin folder. Let's move on to the File Extensions tab. We need to fill out each of the file extensions for each file type. Since our UoCs are written in C++, for header files, the file extension is HPP. For source files, it's CPP. For libraries, it's A. For object files, it's O. Finally, for CentOS, let's put the executable as X. For Windows 10, you would put EXE here, as that's how Windows interprets executable files. Let's move on to the Tools tab. Here, we define where the compiler, linker, and archiver executables are located, so the CTS may use them to generate commands to test a UoC. In the Compiler section, let's define the compiler executable. I have G++ installed as my compiler, so my executable will be G++. Then, the compiler's flags will be shown on the screen. Finally, our output flag will be dash O. The CTS appends a generated output file name after each command, so we only need to supply the output flag. We don't need to supply any libraries to the compiler for our demonstration. Our linker executable will also be G++. Our linker flags are shown on the screen. These flags are used because the target environment that the UoC will be deployed on is most likely not the machine the UoC has been developed or built on. If these flags were not included, then the OS would provide libraries and start files that were not used by the UoC and are not conformant to the face technical standard. Again, the output flag would be dash O, and we do not need to supply any libraries to the linker for our demonstration. The archiver uses the AR executable with CR as the flags. The CR flags stand for create and replace, meaning the archiver will create a library if it doesn't exist, and replace it if it does exist. We don't need to specify an output flag for the archiver in this demonstration. Finally, we can supply a toolchain template file. Let's find the toolchain templates supplied within the CTS at the root directory of the CTS slash data files slash string template and find the default C++ C toolchain templates dot stg file. This toolchain template file in particular has the ability to interpret basic C++ commands, which is exactly what we need for this demonstration. Clicking on the arrows next to template output generates example commands based on the options we have supplied in previous sections. This was also demonstrated in chapter 3 video 3, but we didn't provide any executables, flags, or output flags in that video. Here we can see that the CTS interprets our supplied options and constructs valid commands to test a UOC. Let's click on the compiler specific tab. The exact types definition section allows us to define compiler specific interpretations of fixed width integer types. It is important to note that we are using G++ version 4.8 for our demonstration. In G++, we know that an int 8t is 8 bits, and the minimum size of a char is 8 bits, or 1 byte. The face technical standard uses type defs to define special types of the same size as existing primitive types. The face int 8t is type defed to an int 8t, which we know is a char. For that reason, we can enter char in the field corresponding to face int 8t. This process is repeated for 16 bits, or 2 bytes, and 32 bits, or 4 bytes, filling in short int and int in the face int 16t and the face int 32t field, respectively. Similarly, unsigned integers must be defined as well. Luckily, we just need to add unsigned to the front of char, short int, and int, since we just did the signed versions of those types above. Size t is an unsigned value of size 4 bytes on a 32-bit architecture, and 8 bytes on a 64-bit architecture. This demonstration's version of CentOS is 64-bit, so size t is 8 bytes. Which means an unsigned long int type, which is 8 bytes, should be used for face size t. Our operating system supports 64-bit architecture, so we must enable the supports 64-bit checkbox and supply face int 64t and face uint 64t as well. Just like size t, which was 64 bits, we know that the signed int 64 should be a long int, which is 64 bits, or 8 bytes, and the unsigned int 64 should be unsigned long int, which is 64 bits, or 8 bytes. Next, the UOC may provide a null definition different from the native null definition for C or C++. It may be defined as a macro for the G++ compiler. To demonstrate how this might be written, let's provide alternate definitions of null for C++ and C. We'll write it as a simple if-else macro, as shown on the screen. Now the toolchain will interpret face null as 0 in C++ and avoid pointer in C. For the allowed definitions, GCC creates symbols that might not be faced conformant that must be ignored. More information about the theory behind allowed definitions is contained in Chapter 3, Video 3. This source code that we are going to use as our allowed definitions is shown on the screen. Finally, we will include the OpenGL header files for OpenGL ES, SC, and SC 2.0. They're located at the root directory of the CTS slash toolchain slash compiler-specific slash GCC Linux 4.6 plus. If you're using Windows 10, please select the MinGW folder. The exact location of the header files are shown. The Notes section does not provide any options that are included in the conformance process, so we may ignore this tab. We are ready to check the toolchain's configuration. Click on the Check Configuration button at the top left of the interface to see if we have configured our toolchain correctly. It looks like we have an error in our toolchain configuration. Let's check the report icon for more information about our error. Clicking on the report icon shows each configuration test name and test result. Since we failed one of the tests, that test is at the top and denoted with a red X. It looks like our supplied C++ compiler cannot compile a source file. If we scroll to the right, we can see that there is an issue with the FNoExceptions flag. We forgot to add an S to the end of the flag. If we go back to the Tools tab, we can fix this error by editing the compiler flags. Then click Save and check configuration once again. Our configuration is now valid. With this message, we know that we have correctly configured the toolchain configuration file and we're ready to use it in a project configuration. Thank you for watching. In the next video, entitled Demonstration of a PCS Conformance Test, we will demonstrate how to configure a project configuration file, perform a successful conformance test, and perform a failing conformance test with suggestions on how to recover from possible errors.