WB30 Project Type documentation

Background/Abstract

  • The WB30 Project Type generates project files utilizable by Wind River Workbench, version 3.0. Workbench is built on the Eclipse platform and inherits many of its features. In this document, "eclipse" is used at times to describe features common to both eclipse itself and workbench. The project type generates workbench projects from generic mpc files. These workbench projects can then be imported into a user's workspace and built using the workbench "managed flexible build".
  • MPC's WB30 Project Type currently supports Linux and Windows as both host and target platforms. It can be extended to support other platforms as well.

    • Usage

    For every project myprojname { } in mpc files, the WB30 project type generates a corresponding "workbench project" directory of the form wb_myprojname. The WB30 Project Type uses Eclipse's linked resource feature to work around Eclipse's usual requirement that source files reside inside the Eclipse project directory. However, the linked resource feature also comes with restrictions; see the note for details.

    Generic workflow

    Presuming .mpc files already exist:
    1. Generate projects using -type wb30.
    2. Import projects into a Workbench workspace. From within Workbench (preferably an otherwise-empty workspace) select File->Import... and perform the following actions:
      1. Choose General->Existing Projects Into Workspace and click Next
      2. In "Select Root Directory:" text field, enter the full path to the MPC workspace.
      3. Workbench will scan all the subdirectories looking for existing projects.
      4. Be sure that the checkbox next to Copy projects into workspace is UNchecked. Copying projects into the workspace unnecessarily duplicates files, plus we have found that Workbench can get confused with file paths sometimes (though sometimes it will work).
      5. Click Finish to proceed with the import.

    Building A Project

    To build a project or set of projects, select the project (or projects) in the Project pane, then select Project->Build Project.

    Platforms and Buildspecs

    The default platform for WB30 is called "Native" and corresponds to creating a project in Workbench using File -> New -> Native Application Project. Although this method doesn't have (in workbench) any direct support for building shared libraries, MPC does generate projects that pass the correct compiler and linker flags to create shared (dynamic) libraries. Selecting static or shared libraries with WB30 works the same as with any other MPC project type.

    The alternative platform, "VxWorks" can be selected by passing the option -value_template platform=VxWorks on the mwc.pl command line. Currently the VxWorks support is inherited from the existing -type wb26 template, so it may need some more work before it is production-ready. Note that the wb26 template supported only DKM projects for VxWorks (Downloadable Kernel Modules).

    Each platform includes a list of supported buildspecs, and a single default buildspec. For the "Native" platform, the list of supported buildspecs is:

    Users can select the list of buildspecs by passing the option -value_template buildspecs=<specs> on the mwc.pl command line, where <specs> is replaced by the buildspec value or values. Multiple values are separated by spaces (with the entire specs string enclosed in quotes). Similarly, the default buildspec can be selected with -value_template default_buildspec=<spec>.

    New buildspecs (or even platforms) can be added by either editing the file $MPC_ROOT/templates/wb30dll.mpt (if the modification will be submitted back to the public MPC repository), or creating a file named user_wb30dll.mpt anywhere on the MPC -include search path. Within either of these files, create a scope for the platform/buildspec and use assignment statements within that scope to set the various template variables. The existing buildspecs serve as the best examples.

    Notes

    1. MPC doesn't directly generate Workbench workspaces, because they depend on an unknown binary file format that it can't generate. Instead of generating files that can be loaded as a Workbench workspace, MPC generates two files representing the workspace:
      1. wb30projects.lst
      2. org.eclipse.core.resources.prefs
      wb30projects.lst contains comment lines (starting with #) followed by one line per project, listing the full path to the .project file.
      org.eclipse.core.resources.prefs also begins with comment lines (starting with #) follwed by the contents of one of the files from Eclipse's workspace format, specifically: .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs Unfortunately, this file alone is not enough to actually constitute a workspace because Eclipse uses other binary files in this .settings directory.
    2. WB30 uses Eclipse's linked resource feature to work around the usual requirement that all source code reside in Workbench project directories. These act similar to symbolic links. While convenient so that a developer is not required to conform to Workbench's directory layout, it comes at a price: the target of the link must be specified as a full path. The consequence of this restriction is that, once the WB30 projects get generated, the source directory can not move in the filesystem without re-generating the projects.
    3. MPC's WB30 Project Generator creates directories named wb_* for projects. To remove all WB30 projects from a directory hierarchy, on Linux you can use a command such as: 
        $ find . -name 'wb_*' -type d | xargs rm -rf