We're looking at using jam to standardise our builds. I have read the Laura Wingerd paper on how it was implemented at Sybase. Our own systems are not nearly on the same scale as that, but we do have multiple platforms and compilers to support, not to mention a reasonably complex layering of C++ libraries.

I have not even tried jam yet. Before I do, I would be interested in any insight on these issues:

Questions:

1. The paper describes some in-house customisations done to Jam for Sybase's purposes. The relative path naming one interested me. Did these customisations make it back into the version of Jam that exists today? (Ver 2.3)

2. I am not sure how to handle the issue of debug building, with respect to the source file paths that are embedded into the exe or debug databases. (e.g. on MSVC 6 there is a .pdb file that contains all this stuff.) The problem is exacerbated when a project links in with debug versions of shared libraries. Basically, I want to avoid having to enter paths to source modules in the debugger. I cannot always guarantee that the developers 'root' workspace will be the same, so I am probably in trouble whenever absolute path names get embedded in the debug info. Matters are complicated by the fact that the shared library may not sit in the same workspace location when its being used to build an application, as when it was itself built. In this case, there are problems with both absolute and relative pathing approaches.

What do others do in respect of this?