Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

[ Eclipse Support Documents ]

Eclipse CDT Support

Using Nokia nmake with Eclipse CDT

This page provides information on using Nokia nmake with the Eclipse CDT. Eclipse CDT is an Eclipse-based IDE for C and C++ development.

Effective use of Eclipse with nmake based projects is currently possible (as of Eclipse 3.2/CDT 3.1.1). However, there are areas where interoperability between Eclipse and nmake can be improved. As we develop interoperability improvements, we will post them to this page.

Basic project setup

There are many setup variations possible, this section outlines key settings for one possible basic setup that is sufficient to get started. These instructions were developed using the Linux version of Eclipse 3.2.

Start Eclipse from the project top level build directory. When starting Eclipse, nmake should be on the PATH, and VPATH should be set appropriately in the environment. (Setting these in the make builder environment may be possible for lower level builds, but this is not necessary for the approach taken here. The project make builder environment is specified in a tab in the C/C++ Make Project property window.)

Set up the project using the Standard Make C or Standard C++ Project setup wizards (File > New > Project, then C > Standard Make C Project). On the first C/Make Project wizard dialog page, use the default location to create a project located in the workspace, or uncheck Use default location and enter a path to the project location (can be any arbitrary location in the file system). Enter your project node root or a project sub-directory. Using the project viewpath node root maps your entire project to a single Eclipse project. This has the advantage that you see a complete hierarchical view of the project structure in the workspace navigator allowing easy navigation among project levels.

Continuing with the C/Make Project Settings wizard dialog page, on the Make Builder tab, uncheck Use default and enter "nmake" in the Build command field. Uncheck Build on resource save to avoid repeated builds when saving files. Check Build (Incremental build) and enter your normal nmake build options in the associated text field (for example, "-k install"). Check Clean and enter normal nmake project cleaning options in the associated text field (for example, "recurse clobber"). In the Error Parsers tab, verify that CDT GNU Make Error Parser and CDT GNU C/C++ Error Parser are enabled. You might optionally uncheck error parsers corresponding to tools you are not using, for example, uncheck CDT Visual C Error Parser if you are not using Visual C. Click Finish to exit the wizard.

Click yes if Eclipse offers to open the C/C++ perspective.

The C/C++ perspective will present a C/C++ Projects view along the left side of the main Eclipse window. The new project should appear as a top level entry in this view. In the C/C++ Projects view, right click on the new project and click Properties. Select the C/C++ Make Project property page. Verify that the build settings are set as entered into the wizard (especially verify settings for the Build (Incremental Build) and Clean build targets. In the Build Location field, enter the directory containing the Makefile to be built. The build directory is typically the directory containing the top level Makefile. Select the Workspace... button to browse to a directory in the workspace. Select the Filesystem... to browse to an arbitrary directory in the file system. Alternatively, an absolute or relative path entered directory into the Build directory: text box will set the build location to that location relative to the workspace, if that location is accessible. Click OK to exit the Properties dialog.

From the main Eclipse menu bar, uncheck Project > Build Automatically.

At this point, Project > Build Project runs a top level build in the previously specified Build Location, and Project > Clean... cleans up the build ("clobber" in nmake terms). It is also possible to launch builds from lower level directories. Builds in leaf level directories that directly build executables and libraries are especially useful during development. To create a lower level build target, right click on the desired build directory in the navigator view, and select Add Make Target. Enter a name for the target, the target to pass to make, and the build command, and click Create. Alternatively, enable the Make Targets view by clicking on the target icon in the lower left corner. The Make Targets view allows display and manipulation of targets at multiple levels in the build hierarchy. Create a new target in a directory by right clicking on the directory and selecting Add Make Target. Run an existing target by right clicking on the directory in dialog displayed by Navigator > Build Make Target... or directly in the Make Targets view by double clicking on the icon representing the target.

Basic project setup -- example

Following is a typical nmake based project structure:

ex1/
    src/
        Makefile
        global.mk
        eclipserules.mk
        cmd/
            Makefile
            cmd1/
                Makefile
                a.c
                b.c
                c.c
            cmd2/
                Makefile
                d.c
                c.c
                a.c
        lib/
            Makefile
            lib1/
                Makefile
                lb.c
                la.c
    bin/
    lib/

Although simple, this project exhibits many aspects of larger projects--multiple source directories, Makefiles at different levels of the tree, and separate library source directories. ex1 is the project root containing the src, bin, and lib directories. Following are contents of selected Makefiles.

src/global.mk:

INSTALLROOT = $(VROOT)

/* optional */
include $(VROOT)/src/eclipserules.mk

src/Makefile:

include $(VROOT)/src/global.mk

:MAKE: lib - cmd

src/cmd/Makefile:

include $(VROOT)/src/global.mk

:MAKE: *

src/cmd/cmd1/Makefile:

include $(VROOT)/src/global.mk
.SOURCE.a : $(LIBDIR)

cmd1 :: a.c b.c c.c -llb1

Complete source for this project is available in tar archive ex1_lu38.tar.gz. eclipserules.mk is an optional include Makefile, discussed in section Compilation error parsing, that redefines directory recurse messages to a format compatible with CDT.

Start Eclipse from the project top level build directory ex1/src. When starting Eclipse, nmake should be on the PATH, and VPATH should be set in the environment. Since this project has only a single node, for this example set VPATH to the absolute path leading to the viewpath node root directory ex1, for example something like $HOME/workspace/ex1.

On the first page of the Standard Make C Project Wizard, enter the path to ex1 as the project location (in nmake terminology, this would be the viewpath node root). On the C/Make Project Settings wizard dialog page, on the Make Builder tab, enter "-k install" in the Build (Incremental build) text box. Follow remaining instructions as described in section Basic project setup.

After the project is created, select the project in the C/C++ Projects view, then Project > Properties to bring up the project property editor. On the C/C++ Make Project page, set Build directory to ex1/src. (This will be relative to the workspace root if the project is located in the workspace.) Set remaining fields on the page as described above.

At this point, with the project directory still selected in the C/C++ Projects view, Project > Clean should do a top level project clobber, and Project > Build Project should do a top level incremental project build.

Say you are working in ex1/src/cmd/cmd1 and want to do a local build there. On the C/C++ Make Project page, right click cmd1 then select Create Make Target.... Enter the target name, desired makefile target, build command, and click Create to create a local target. Launch the target by again right clicking on cmd1 and selecting Build Make Target.

Alternatively, bring up a Make Targets view by clicking in the Eclipse window lower left corner. This will display nmake targets in the build tree. Right clicking on a target or double clicking the target will launch it.

For our example project, the Make Targets tree view looks like:

eclipse make targets

Three local nmake targets are shown: two in directory cmd1, and one in directory cmd2.

Compilation error parsing

Eclipse analyzes build output and creates markers indicating the location of compilation errors. Double clicking on a marker in the Problems view opens an editor at the location of the problem.

However, Eclipse cannot parse default nmake build recursion messages, leading to inability to associate compilation errors with source locations when a project contains non-unique source filenames.

An nmake rules file is available that fixes this problem. It works by redefining the build recursion messages to emulate the messages output by GNU make. It works for arbitrary recursive invocations of nmake (not just for :MAKE: or :cc:) and is completely automatic, requiring no special Makefile changes or options. The approach has the additional advantage of allowing interoperability with other compilation error tracking tools such as GNU Emacs compilation mode.

The rules implementing this alternate recursion message format are available in a file called eclipserules.mk for use with current nmake releases, and are scheduled for inclusion in future nmake releases. To use eclipserules.mk, simply include the file in your global project rules or directly in your Makefile:

include eclipserules.mk

See section Basic project setup -- example for an example use of eclipserules.mk.

eclipserules.mk configures nmake to output recursion messages similar to:

make[1]: Entering directory `/home/abc/dir/subdir'
make[1]: Leaving directory `/home/abc/dir/subdir'

eclipserules.mk notes:

  • eclipserules.mk is only tested for use with nmake release lu3.8. Contact us if you would like to use it with another release.

  • CDT 3.1.1 or better is required.

  • eclipserules.mk introduces a variable MAKELEVEL representing recursion levels. eclipserules.mk uses MAKEEXPORT to pass MAKELEVEL down to recursive make invocations completely automatically. This has the undesired side effect of printing shell export messages for each triggered shell action. A fix for this problem is planned. In the meantime, a simple shell filter provides an effective workaround. For example, put the following line in file mk and use mk in place of nmake when running a build.

    mk:

    nmake ${1+"$@"} 2>&1 | egrep -v '^\+ MAKELEVEL=|^\+ export MAKELEVEL$'
    

    To use from Eclipse, put mk on your PATH and set the CDT build command to ksh mk (ksh is required for use from Eclipse CDT.)

Note

Remote use of Eclipse is possible. We have had good results running Eclipse over a standard X session on a LAN. Also, we have heard reports that remote Eclipse sessions run well over vnc.

Issues

Viewpathing

Eclipse does not itself support viewpathing. However, viewpathing works fine in nmake-based builds launched from Eclipse. A natural approach is to define a project in the top viewpath node, and perform edits and kick off builds from there. Typically the top viewpath node contains only the subset of source files under development. When the project is defined in the top viewpath node, these files are visible to Eclipse and can be viewed and edited. However, Eclipse does not seem to be able to pull in source external to a project that is referenced during a build, so source files down the viewpath are not visible. (This behavior may be dependent upon build output scanner configuration.) An option is to copy or link source files in the working directory, plus referenced header files, into the top node. This approach has the advantage that project directories not under development do not clutter up the Eclipse workspace. Another option is to add header directories to the Eclipse include search path.

The best solution is to make Eclipse itself viewpath-aware. This has not been possible in Eclipse 3.1 and earlier, since the org.eclipse.core.resources plugin, the core Eclipse component that manages workspace file resources, was tightly coupled with the local file system. Eclipse 3.2 introduces a new filesystem abstraction called the "Eclipse File System" (EFS), providing a framework allowing development of plugins that contribute alternate file systems to Eclipse. Initial experiments with this approach look promising, however CDT, of release 3.1.1, does not provide the needed support for EFS (for example, see Eclipse bug 142092 - CDT EFS Support). We plan to continue to explore support of viewpathing through EFS as soon as CDT support for EFS becomes available.

Makefile editor

The Eclipse Makefile editor does not recognize nmake comments or user defined assertion statements, leading to error markers in the Makefile outline view. These markers are harmless. We plan to investigate this issue further.

Last Update: Friday,12-Aug-2016 10:55:17 EDT