 Welcome to the CTS learning series, Chapter 6, Testing an OSS-UOC Example. Video 4, Demonstration of an OSS Conformance Test. In this video, we will demonstrate the construction, validation, and successful conformance test execution of a project configuration file for an OSS-UOC. In our case, we will be testing the GNU C++ Standard Libraries on CentOS 7. In addition, we will explore the Object Libraries tab, how it may change based on the option selected, and why it changes. Let's first open the Project Configuration list and make a new project configuration. Let's name it, CTS Learning Series, OSS Demonstration. And we'll save it in the CTS Learning Series directory. After clicking OK, we are presented with the Project Configuration Builder. For this video, we will be demonstrating the construction of the PCFG. But for more information about each of the options provided in the PCFG, please refer to Chapter 3, Video 4. Let's set our base directory to Home, CTS User. Next, our segment is going to be OSS. Our language will be C++, since we are testing the C++ Standard Libraries. And the tool chain that we will be using is meant for C++ UOCs. In selecting the language, we dictate what is available to be selected in the Object Library tab. If we select other languages, the Object Library tab will change as well. Let's keep this in mind as we continue configuring our project configuration file. Our profile will be general, as that's what we set our tool chain's OSS profile to be. CentOS is entirely built on a POSIX partition, so we must pick POSIX as our partition. Let's link the OSS tool chain we made in Chapter 6, Video 3, in the Tool Chain option. Finally, let's set the UOP name to CTS Learning Series, OSS Example. If we notice on the left side of the CTS, the Data Model tab is grayed out. This is because OSS UOCs do not contain data models. If we remember from Chapter 4, a data model describes data passed into or out of PCCS or PCS UOCs. As stated in Chapter 6, Video 2, an OSS segment provides capabilities, libraries, and an operating system to support UOCs or units of conformance. For that reason, OSS UOCs do not describe data between PCS and PCCS UOCs, which is why OSS UOCs do not contain data models. This can be further visualized by the shown diagram of the face architecture. Although we stated in Chapter 6, Video 2, that most OSS UOCs, including the tests we are about to perform, does not require the generation of GoldStanded Libraries, we must enter a GoldStanded Libraries path for that edge case. Let's set the path to an empty directory. In our case, let's set it to Home, CTS User, GSLs. Let's now click on the Object Libraries tab and pause to look at what's shown. At the top of the section, we have a number of tabs, C++ Standard Library, HMFM, Configuration, and LCM. When we first click on each tab, the options contained in each tab are not editable. Save for the top checkmark. Clicking on that top checkmark enables the options to be edited. These top tabs are dependent on the language and OSS profile that was selected in the General tab. Here, we show what options are available based on the language and OSS profile that was selected in the General tab. We will select the C++ Standard Library, as that's all we're going to be testing from our operating system. It is very important to note that G++, our compiler, is from GNU. The C++ Standard Libraries that GNU supplies are not face-conformant. For that reason, although most C++ Standard Library tests will pass because the Standard Library contained in GNU is close to providing the functions needed to supply a face-conformant UOC, we are expecting some C++ Standard Library tests to fail. Testing the C++ Standard Libraries requires a C++ compiler to be executed and object files linked together. The compiler flag and linker flag options are provided. Then, an object library section, compiler path section, linker path section, and include file section are provided. The object library section allows the user to define any OSS-specific objects or library files to be directly linked into the C++ compiler. The compiler paths provide a way for the user to define any file paths that the C++ Standard Library is located in. Because we're only testing for the C++ Standard Library that is contained in this distribution of GNU, we must provide the compiler paths to the C++ Standard Libraries. A complete list of the directories to be included for the GNU C++ Standard Libraries is shown. The linker paths allow for the user to provide any file paths that the C++ Standard Library may need to be linked to. We're not going to provide any linker paths for the purposes of this demonstration. Finally, the include file section allows the user to provide any file paths we may need that are outside the scope of the compiler, linker, and is not an object or library. We're not going to provide any include files either. Below that, the factory functions file option is provided. More information about factory functions can be found in chapter one and chapter five. This demonstration does not require factory functions, so we may leave this blank. Below the factory functions option, the user may define what interfaces the OSS uses. We won't be using any for this demonstration. We also won't be using the notes or project info tabs in this demonstration, so it's time to verify our configuration. Clicking on the verify button checks our configuration for correctness. It looks like our project is valid and ready for the conformance test. Let's click on the test UOC conformance button. The progress bar will fill up as the conformance tests are being performed. After the conformance test is completed, we are shown a conformance test result. In our case, we have failed our conformance test, but this is expected as we mentioned earlier. In chapter six, video five, we will open the conformance test report and talk about the test results for OSS UOCs. Thank you for watching. In the next video entitled review of testing result, we will open the conformance test report, examine the contents of the report, and explain the conformance tests that resulted in failure.