System Libraries

Obviously, your code doesn't just link with your libraries. It also has to link with some of the system libraries. Jam manages this by using the LINKLIBS variable. The simplest way to make this work is something like the following:

LINKLIBS on emplode.exe += ws2_32.lib ;

empeg's source tree has a directory called lib, in which the core libraries used by all of our products live. Unfortunately, this conflicts with one of the included pseudo-targets that jam uses.

The fix is relatively simple. You need to edit the included Jambase file, and rename every mention of lib to something else, e.g. libs.

Jam imposes a hard limit of 996 characters on command lines when built on NT. This limit is higher for other operating systems, and can actually be raised to around 10Kb on Windows 2000. However, it's still not high enough for some link actions.

First, you'll need to download jam version 2.3.2 from ftp.perforce.com in zip format or as a tar.gz

Unpack the contents into a new directory. Edit the Makefile, and uncomment the relevant lines under the comment:

# NT (with Microsoft compiler)

Introduction

Jam is a replacement for make(1). See here for more details.

I'm attempting to use jam to build our Windows code, but in order to keep the scale of this discussion down, I'm just going to explain the aspects of our codebase that caused difficulty, and then I'm going to fake them up in a mock build tree. This will enable me to explain things in isolation.

By default, AppWizard-generated applications use separate directories for the output of the different debug and release builds. We'd like to replicate that functionality.

Introduction

empeg's code base contains several Windows DLL projects. I'm going to investigate getting these built with jam the same way as I did for the MFC applications -- by building a simple project with the AppWizard, and getting the project built.

Introduction

Since the majority of our Windows applications are written using MFC, it's a useful experiment to get jam to build a freshly-generated MFC application. Once we've got this working, we can turn our attention to the things that make our build process different.

I've attempted to break down the process of getting an MFC application to build into discrete chunks. They're not particularly self-contained at the moment, but they attempt to describe one problem (and hopefully its solution) each:

The default Jambase file doesn't come with a rule to make DLLs (or shared libraries in the Unix parlance).

The fix consists of cloning the Main and MainFromObjects rules, and modifying them as follows, to create a SharedLibrary rule.