[jamming] Jam2.5 and precompiled headers

Craig McPheeters cmcpheeters at aw.sgi.com
Mon Feb 3 10:36:09 PST 2003

> Subject: Re: [jamming] Jam2.5 and precompiled headers
> From: Matt Armstrong <matt at lickey.com>
> Date: Sat, 01 Feb 2003 09:56:07 -0700
> "Chris Antos" <chrisant at windows.microsoft.com> writes:
> > Between batch compilation and precompiled headers, the latter gives
> > a bigger win.  Combining the two gains some additional improvements
> I've also looked into trying to get visual c++ to support parallel
> builds (-j 2).  Unfortunately, the compiler barfs because it wants to
> build a .pdb file.  :-(

I needed to solve this problem for a build I was working on at the time.
We are using pre-compiled headers and .pdb debugging - I don't think its
possible to use that combination with the standard version of jam.

There is /Z7 and /Zi debugging available.  /Z7 placed the debug info into
the .obj file, /Zi places the debug info into an external file which you can

With pre-compiled headers, you'll compile a single file with a switch to
generate a pre-compiled header file (.pch) and then provide that file on some
set of files (all the files for a library, all the files for a .dll, etc.)

Using multiple jobs with .pch files is easy, just set it up.  Using multiple
jobs with .pdb debugging is possible, if you specify a different database
for every .obj file.  But this makes the build area quite a lot larger than
normal.  If two compile actions are running at the same time with the same .pdb
file, one of them will fail as they both want to open the file to write into,
and they both can't do that.

When you use .pch files with .pdb files, the compiler demands that the .pch
file provided was compiled with the same .pdb file that the current .obj file
is using.  This means that for some set of .obj files, they need to be 
compiled with the same .pch and .pdb file, which means that only one of those
compiles can be executing at a time due to the file lock problem.

I solved this problem in my version of jam by introducing a semaphore node.
You assign a semaphore to a node by setting its JAM_SEMAPHORE variable.
Something like:
   JAM_SEMAPHORE on $(target) = $(dll-semaphore) ;

The same semaphore node is assigned to all of the files which would share the
same .pdb file.  Jam then ensures that only one action is launched at a time
for each semaphore.  I can then use multiple jobs, and as long as there is
work for the build (if you're building multiple .dll's or libraries) then
multiple jobs will be launched.

The code for this is available in my public branch.  

In the Jamfile.config file in that branch, look for documentation on the 
OPT_SEMAPHORE define, which is how you turn it on.


> _______________________________________________
> jamming mailing list  -  jamming at perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming

Business phone:  VNET: 8670   or   (416) 874-8670   or   (206) 789-1374

More information about the jamming mailing list