Doug Abbott: Embedded Linux development using Eclipse

cvs –d /usr/local/cvsroot init

Back in the CVS Repositories view, right-click and select New→Repository Location…. This brings up the Add Repository dialog we saw in Figure 8.19. This time the entries are:

Host: localhost

Repository path: ( /usr/local/cvsroot)

User:

Password:

Connection type: extssh

The new repository looks something like Figure 8.23. The HEAD and Versions nodes have the requisite CVSROOT entries, but are otherwise empty, as is the Branches node. Our next task then is to add a project to the repository that we can share with other members of our team.

Figure 8.23: New local CVS repository.

Let’s use the thermostat project as an example. Go to the C/C++ perspective and right-click thermostat in the Project Explorer view. Select Team→Share Project…. The first dialog box gives you the choice of using an existing repository or creating a new one. Highlight your local repository and click Next. Here you have a choice of module naming options. Keep the default, Use project name as module name. Click Next. [13] I encountered an error at this point: “Errors saving CVS synchronization information to disk.” CVS created a hidden directory, .settings, in the project workspace that is owned by root and not world-writable. Changing the permissions fixed the problem.

The next dialog lets you select which of the project’s resources to share (Figure 8.24). Typically you want to share all of them. Click Finishto launch the Commit wizard.

Figure 8.24: Share Project Resources dialog.

Interestingly, the Commit wizard finds a couple of files with “unknown names or extensions” and asks you whether they are binary or ASCII. .cdtprojectis in fact ASCII. thermostat_sis binary. Finally, you can enter a comment for the commit operation. Something like “Adding new project” might be appropriate.

The thermostat project is now identified as being under CVS control on the localhost and all the resource files have version numbers. Back in the CVS Repository Exploring perspective, thermostat now shows up as an entry under HEAD in your local repository.

Having committed the project to CVS, we can continue working on our own copy in the workspace and later synchronize any changes with what’s in the repository. Make some minor change to thermostat.c, add a comment, perhaps. When you save the changes, greater-than signs (>) appear next to the project name and the file, indicating changes that will need to be checked in to the repository.

Right-click thermostat.cin the Project Explorer view and select Team→Synchronize with Repository. This brings up the C Compare Viewer, showing the differences between the Local File on the left and the Remote File in the repository on the right (Figure 8.25). Icons in the tool bar let you step through the differences. You can also copy any non-conflicting changes from the Remote File to the Local File, that is, from right to left.

Figure 8.25: C Compare Viewer.

Where a team of developers is involved, it’s quite likely that the file in the repository, the Remote File, contains changes from someone else. The C Compare Viewer highlights those changes as well. In practice, you should perform a Team→Updateoperation on the file before synchronizing with the repository.

Now you can commit the new version back to the repository. Right-click thermostat.cand select Team→Commit…. This operation is also known as “checking in.” You’re prompted to enter a comment for the commit operation. Then click Finish. The new version is written back to the repository.

For completeness, we’ll also go through the process of checking a project out of the repository. In the C/C++ perspective, delete the thermostat project. When prompted, check Delete project contents on disk. Now go back to the CVS Repository Exploring perspective and right-click on thermostat. Select Check Out. The project is copied to your workspace and built.

To wrap up our exploration of CVS, we’ll look at the branching process. There may be any number of reasons why you would want to create branches for a project in addition to HEAD. Maybe there are multiple versions of a product, in which the software builds differently for each version. Make each one a branch. You might want to establish a developmental branch separate from the production branch.

In the C/C++ perspective, right-click the thermostat project and select Team→Branch…. Give the branch some sensible name (Figure 8.26) and leave the Start working in the branch box checked. CVS proposes a Version Name. The version name identifies the point at which the branch was created, and is necessary later on when you want to merge the branch.

Figure 8.26: Create CVS branch.

The branch name shows up next to the project name. Back in the CVS Repositories view, expand the Branches node of your local repository. You’ll see the branch you just created and under it, the thermostat project. Now, when you do a checkout or a commit, you’re working with the newly created branch and not HEAD.

In this chapter we’ve looked at two advanced features of Eclipse, one built-in, and the other an add-on, that can greatly improve software productivity and reliability. UML is a powerful tool for visualizing complex software and deriving code templates from the graphical models. Although most open source UML tools tend to be oriented to Java, there’s nothing to prevent tools that have a C++ flavor. Eclipse plug-in Central lists 35 plug-ins in its UML category. It might be worth checking some of them out.

CVS is an integral part of Eclipse that brings some order to the potential chaos of team development. Project resources are checked in and out of a central repository in an orderly fashion, and conflicting changes can be easily identified for resolution. CVS tracks every change so that the code can be rolled back to any previous version if necessary.

In the next and final chapter we’ll look at how three embedded Linux vendors have adapted the open source Eclipse platform to build commercial products that address various aspects of the embedded development process.

UML

Fowler, Martin. 2003. UML Distilled: A brief guide to the Standard Object Modeling Language . (3rd ed.) Addison-Wesley.

Miles, Russ, and Kim Hamilton. 2006. Learning UML 2.0 . O’Reilly.

Bruce Powell Douglass has been particularly prolific in writing about UML for embedded and real-time applications. His titles, all published by Addison-Wesley, include:

Douglass, Bruce P. 1999. Doing hard time: Developing real-time systems with UML, objects, frameworks, and patterns . Addison Wesley.

Douglass, Bruce P. 2004. Real-time UML: Advances in the UML for real-time systems. (3rd ed.) Addison Wesley.