blueDonkey.org

This Web

All Webs

blueDonkey.org

Other Sites

Development Environment

• Configuration Management
  • Choosing a Tool
  • Importing Third Party Sources
  • Additional CM Tools
    • Local Repository Browsing
    • Web-Based Repository Browsing
    • Graphical Merge Tools
• Toolchain
  • Selecting a Version
  • Building a Cross Compiler
  • Using an Alternate C Library
  • Using a Pre-Compiled Toolchain
• Debugger
  • Native Debugging
  • Remote Debugging
  • Kernel Debugging
  • JTAG/BDM Debugging
• IDE
  • Empowering Your Developers
  • Integrated Development Environments
• Tracking Toolchain Changes
  • When to Upgrade
  • Vendor Branches

Configuration Management

Choosing a Tool

An important aspect of working with any third party source code is being able to track their changes, and merge them with any local modifications. If you already use a configuration management system then this will almost certainly be able to handle this for you. If you don't already have one, then I strongly recommend that you take the time to get one and learn how to use it.

Since it is widely used in the open source community, I will describe the use of CVS here, but the same principles can be applied to any configuration management system. Just for interest, the Linux kernel source is maintained in a number of different CM systems by individual projects, but the central repository for kernel sources is using the BitKeeper CM system. You can browse the kernel sources at http://linux.bkbits.net/ and also review changes or generate diffs between arbitrary versions of a file, all through your web browser.

Importing Third Party Sources

When dealing with third party sources it is important to keep them in a separate branch from local changes. This will allow for easy upgrades to new versions in the future. CVS handles this using vendor branches which are created automatically by the import command. The basic idea is shown in the diagram below:

Figure 2.1 - Vendor Branches

For example, to import the sources for version 2.3.0 of a product called pLib from pSoftware for the first time, one might execute the following command:

cvs import PSOFTWARE PLIB_2_3_0 pLib

By convention the tags are all upper case. pLib will be the name of the module (and also the default name of the directory when the module is later checked out).

To later update to version 2.3.1 simply execute the following command:

cvs import PSOFTWARE PLIB_2_3_1 pLib

CVS will automatically tell you if there is any need to merge the new version into your product branch(es). In all probability, unless you have made no changes to pLib and do not use any branches of your own, you will need to merge this new version into your product branch(es):

cvs update -jPLIB_2_3_0 -jPLIB_2_3_1

That may generate conflicts, which are places where CVS is unable to combine changes that the vendor has made in this release, with changes that have been made locally in the same area of a source file. There are some graphical tools that will help with this process. We will look at these in the next section.

For more information about this read chapter 13 (tracking third-party sources) of the excellent Cederqvist CVS Manual available on the http://www.cvshome.org/ website.

Additional CM Tools

There are some tools that make using a CM system more convenient. Most commercial systems will come with these tools, and often many more. Free systems, such as CVS, often have these tools as well, but the end user will need to install them. The following describes a general type of tool, and then an example of an implementation of that feature for CVS.

Local Repository Browsing

There are times when it can be exceptionally useful to be able to browse the versions of a specific file, read the change log messages and even generate diffs between any two versions of a file. Having a graphical form of the version tree can make this easier to navigate, as can seeing the diffs in a side-by-side format with colour highlighting for the changes. Most, if not all, commercial systems offer this kind of functionality as a standard feature.

For CVS, I recommend installing the excellent cervisia product available from http://cervisia.sourceforge.net/ as well as in package form for most popular Linux distributions - check your system, you might already have it installed.

Web-Based Repository Browsing

Less useful for day-to-day work, web browser based repository browsing can still serve a useful purpose, especially for those engineers who find themselves on the road with a current version of the file, but no direct access to the repository data. Again, most commercial CM systems will have web interfaces now, and CVS also has a number of these:

• cvsweb available from http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/

• ViewCVS available from http://viewcvs.sourceforge.net/ which is a development of cvsweb.

Use of these is optional, but can be very useful, even if just limited to an intranet, for remote users who wish to browse versions or check diffs without needing full repository access.

Graphical Merge Tools

Perhaps the most important tool in any CM system is the graphical merge tool. Manually resolving merge conflicts can be tedious and error prone. Having a reliable and simple graphical merge tool can make resolving the inevitable conflicts much faster, not to mention more accurate. Again, commercial systems should include this capability (it should definitely be on the requirements list when spending money on a CM system).

For CVS, my recommendation for this is the same as for local repository browsing: cervisia. Also worth a mention here, though not strictly speaking a CM tool, is xxdiff available from http://xxdiff.sourceforge.net/ which is an exceptionally useful file and directory diff'ing tool that also includes three-way merging capabilities (useful when merging two sets of divergent changes to a file that share a common ancestor) and can be used to help resolve CVS merge conflicts if necessary.

Toolchain

Selecting a Version

The choice of toolchain for most Linux development is simple: GNU. There is pretty much no reason to select an alternative toolchain, and doing so will not only cost money for the licenses, but also extra time during development maintaining a build environment for Linux that uses this compiler.

Luckily, most VxWorks users will have been using GNU already, so this should not be a real problem. Those who opted for a third party toolchain should find that the GNU compiler is more than capable of compiling their source without any problems, and on most architectures today generates code that is as good as any commercial toolchain. Having run extensive benchmarks and other usability studies between GNU and other compilers while at Wind River, I personally would not recommend any of these expensive commercial toolchains, even Wind River's own Diab one, for VxWorks development, letalone for Linux development.

That was the easy part though; choosing the exact version of the GNU compiler version is a little more complex. There are a number of factors that need to be considered:

• Versions with tested Linux support for your chosen CPU

• Versions with the appropriate C dialect

• If C++ is important, versions with good C++ language and library support

• Version included with your embedded Linux distribution

For most development now I would recommend the latest 3.x version that has been used with your chosen CPU (or at least the same architecture). If your board or CPU vendor has a Linux distribution (and most do now), check with them to see what version they are using. Unless there is a very good reason to use a different version, this is probably the one to go with. For the remainder of the toolchain components, usually referred to as binutils, use the version that matches the compiler version you have chosen. For most 3.x compilers this will be binutils 2.13.2; for 2.9x compilers 2.10.1 seems to be the most common choice. Of course, if you are using an embedded Linux distribution, then stick with the version of the toolchain that they supply.

Most versions of VxWorks have shipped with either 2.7.2 or 2.96 (a Wind River version that was based on 2.95 source with some local bug fixes applied). Upgrading to version 3.x should not be a problem for well written C code, but might require some updates for places where the code is not totally ANSI compliant. I would strongly recommend for embedded systems that all locally generated code at least is compiled using the -Werror flag to upgrade warnings to errors. Many warnings that modern compilers generate are early indications of a problem that might be much harder to debug at runtime.

Building a Cross Compiler

Using an Alternate C Library

Using a Pre-Compiled Toolchain

Debugger

Native Debugging

Remote Debugging

Kernel Debugging

JTAG/BDM Debugging

IDE

Empowering Your Developers

Integrated Development Environments

Tracking Toolchain Changes

When to Upgrade

Vendor Branches

-- JohnGordon - 16 Dec 2003