Knowledge Library
Knowledge Library Home
Knowledge Library Home Knowledge Library Products Operating Systems Wind River Linux Wind River Linux 8 Getting Started Wind River Linux Demo Series: Compiling Target Applications — Video, 07:06

Wind River Linux Demo Series: Compiling Target Applications — Video, 07:06

Table of contents

In this video, you will learn how to build applications for your target using Wind River Workbench.

Published on 29 December 2014


Time (mm:ss) Narration
From: 00:00 Hello, and welcome to the Wind River Linux with Workbench 4 demo Series. This tutorial covers compiling target applications in Workbench. When developing target software with the Wind River Linux product, there are several key software development elements to keep in mind. The cornerstone of these is the platform project, also referred to as the build environment. This is a collection of scripts and metadata that provides all the built-in software for the device. So it includes things like the kernel, all of your command-line utilities, and the target image itself. The platform project is also used to provide other essential components that feed into the application development lifecycle, such as the sysroot and the SDK. A sysroot is a generic component supported by the GNU compiler collection that provides all the content needed to build applications for a particular target. This includes your header files, and your static and shared libraries. Essentially, this is just a collection of files that override the standard set of header files or libraries you typically have installed in the root directory in
From: 01:03 a self-hosted development environment. An SDK on the other hand, is a standalone package that includes everything needed to develop software for your target. This includes a sysroot, it includes the cross-compiling toolchain, and it includes other various utilities used to generate software for that particular platform. In cases where the target BSP supports a simulator, the simulator environment is also included in an SDK. While command-line cross development is fully supported by SDKs, Wind River Workbench doesn't have the capability to use an SDK directly. Rather, it uses a concept of a build spec to abstract toolchain details. Build specs specify things such as the location of your toolchain within the local file system, your cross-compile prefix, the location of your sysroot, and additional target-specific compiler or linker flags required to build software for your target.
From: 02:00 Workbench comes out of the box with a default build spec called "native-standard-native", and this represents your host tool configuration. So this is used for self-hosted development for compiling applications which you will run on your development host. For developing software specific to a particular target, you need to add additional build specs based on your target SDK. Now I'm going to illustrate how to access the build specs from within the Workbench interface. The first method involves right-clicking on the project within the Project Explorer view, then from the context menu selecting "Build Options", then within that sub-menu selecting "Set Active Build Spec", and then an additional sub-menu will pop up displaying all of the supported build specs for this particular project. Notice that at the current time there's only one available build spec, and that is the native-standard-native build spec, which represents self-hosted development. Also notice that there's an additional Debug Mode setting, which you can set independently of the other build specs. This allows me to compile my application with or without debug information.
From: 03:02 Please note, this option is available for managed builds only. The second way to access build specs is to simply click on the icon within the Project Explorer toolbar, and this directly presents a pop-up menu that allows me to select build specs, and to enable or disable debug mode. So when it comes time to add target- specific build specs into Workbench, it's good to know that Workbench automatically generates build specs for platform projects under its control. So this includes platform projects which you originally created from within Workbench, or it can also include platform projects which you created from the command line but then subsequently imported into your workspace. So if you happen to be the individual within your organization that is maintaining both the platform project, and the application projects, then this is a good option for importing your build spec into Workbench. So now I'm going to show you how easy it is to import an existing platform project into my workspace. So from the Workbench "File" menu, I'm going to select "Import", and then from the Import dialog I'll expand the "Wind River Linux" item,
From: 04:01 and then select "Existing Wind River Linux Platform Project into Workspace". Then I will click the "Browse" button to locate my platform project within my local file system, and once I locate the directory containing that build environment, I simply select "OK". I can choose to rename how the project appears within my Project Explorer view, but I'm just gonna leave it as it is and select "Finish". And immediately the platform project is visible within the Project Explorer view, and the associated build spec is automatically created for me. Now if you do not happen to be the individual who maintains the platform project, then Workbench also supports the ability to create a build spec from an SDK. SDKs can easily be generated from a platform project, and can be passed on from the platform project developer on to other team members who can then install them as standalone components into their own development hosts. Once the SDKs are installed, it's then easy to import them into Workbench and incorporate them into your application projects. Now in this case, I don't have direct access to the platform project for my target.
From: 05:00 So instead, I'm going to create a build spec based on the SDK which I have installed on my development environment, which is also very easy. From the window menu in Workbench, I select "Preferences", and then from within the Preferences dialog, I expand the "Wind River" item and then select "SDK". Next, I click the "Add" button and then locate the directory in my development host that contains the SDK. Once I've located that directory, I then click "OK". Workbench validates that as a valid SDK, and then I click "OK" again, and now my build spec is available for developing future application projects. Regardless of the method I chose to create the build spec, the net result is the same. I now have a build spec that can enable Workbench to cross-compile applications for my target. So now I'm going to show how to use that build spec to cross-compile this particular application. All I do is I simply click the icon within the Project Explorer toolbar, then select the build spec representing my target. When prompted to rebuild the index, I simply click "Yes". And now I'm going to actually build my project by
From: 06:01 right-clicking on it within the Project Explorer view, selecting "Build Project", and after a short time, my application is built. So then I can go and run it on my target, and now I'm ready to be productive. In summary, when you don't have access to a platform project, SDKs are an excellent way to build target applications using command-line techniques but, when you're working within Workbench, Workbench cannot use an SDK directly. So, from an SDK, you must derive your build spec. There are three different ways to derive build specs within Workbench. The first is to create and maintain the platform project in Workbench. The second is to import the platform into Workbench, and this assumes you have access to the platform project. And, lastly, to use an SDK generated by the platform project developer. Once you import your build spec, then applications, or any Workbench project for that matter, can easily be cross compiled for a variety of targets. Thanks for watching the Wind River Linux with Workbench 4 demo Series.
From: 07:02 Be sure to check out the rest of the series and have a great day!

Contact: dwinters

Content ID: 044795

Last modified