Introduction: Using Projects

To make the most of Micro Focus Visual COBOL and Enterprise Developer, developers are recommended to move towards a project based build system. Over the years I have spoken to a number of people who have kept their existing build system, which are often simply a bundle of build scripts, without making the most of what the product has to offer. I believe that part of the reason people may not have tried project based builds is that the benefits are not well understood, which I will attempt to address in this post.

Note that I will be talking about the Visual Studio (VS) project system which uses MSBuild, but the majority of the points will apply also to Eclipse projects. The key difference being that Eclipse uses Ant for its builds instead of MSBuild.

1. More than IDE boilerplate, build on the command line as well

When a developer creates a COBOL project in VS, a .cblproj file gets created which defines the project. It contains the list of added files, directives, build configurations (release/debug) and additional project settings. The .cblproj file is in a standardised format, much like the .csproj file for C# projects, that is understood by the MSBuild tool.

Some developers don't realise this, but the project file (.cblproj) is not purely just for enabling the Integrated Developement Environment (IDE) tooling. It is essentially a build script and can be built directly on the command line, as well as from within the IDE. The project file is an XML document, so can be directly viewed easily. The build process is handled by the MSBuild tool which reads the project file and invokes the COBOL compiler as appropriate. It is also possible to extend MSBuild to handle any complex build steps required that may not already be available.

Developers coming from a strong mainframe background may be unfamiliar with this, but there is no need to add and remove COBOL sources when working with them in the IDE. The project is more than just a working environment for the IDE, but in fact defines the build environment. This allows the IDE to parse the sources with the same directives that would be used in a build, giving more accurate information to the developer within the IDE (e.g. code errors, completions etc).

In an ideal situation, the developer should be using the same project that is going to be built on a build server or CI machine.

 2. Incremental builds, only compile what's changed

Building within projects provides file dependency checking, allowing for incremental builds. After an initial build, only sources that have changed will be rebuilt, saving time especially for large applications. This applies to both building within and outside the IDE.

For example, if only the copybook foo.cpy has been modified, then only programs that copy it will be rebuilt during the next build operation. This is similar to the functionality of tools such as ant and make.

3. Faster builds with parallel compilation

When building COBOL using projects, it is possible to speed up builds by compiling multiple sources at the same time. This requires the machine to have multiple CPU cores to take advantage of this. There are two varients of this:

• Build projects in parallel
• Building COBOL source within a project in parallel

Which is faster will depend on the structure of the sources and projects. If there are many projects, then the former is better; whilst the latter is more suitable when there is a single project with many sources.

4. Target multiple environments and configurations

Within the project file, it is possible to define properties that control the build. There are some default properties such as configuration and platform. This allows a developer to quickly build for different configurations and platforms.

msbuild loans.cblproj /p:configuration=release;platform=x86
msbuild loans.cblproj /p:configuration=debug;platform=x64

5. Deep IDE Integration

Project files are required for the IDEs to work at their best. Most importantly it tells the IDE what directives the COBOL sources will be built with and the location of the COBOL sources themselves. This is in turn used to drive many IDE features such as syntax parsing, error list and IntelliSense. With all the sources grouped in one place, searching is simplified with tools such as Find-All-References and Go-To-Definition. Additionally, this allows for the sources to be built within the IDE and easily debugged.

Afterword

I hope I've been able to demonstrate some of the benefits of using a project system. I'll be looking to write a short piece on how to go about moving existing build systems to a project system.