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:

Our MFC application has a resource script. This resource script suffers from a minor problem: It’s not dependency-scanned. If we edit any file included by it – for example the .rc2 file, it’s not rebuilt properly.

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.

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

Introduction

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

Introduction

Introduction

While getting our MFC application to build with Jam, we got to a point where it would compile and link, but wouldn’t run. This calls for a trip into the debugger. The simplest thing might be to just run the executable within Developer Studio.

Introduction

Introduction

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