Re: [jamming] JAM Questions: BUilding for debug

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-14 11:54:06

----- Original Message -----
From: "Milton Taylor" <mctaylor_at_[hidden]>

> 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 am working on a build system constructed on top of Jam which is designed
to address the multiple-compiler multiple-build-variant problem. I hope to
have a version ready for public inspection in the next few days, and would
welcome participation from members of this list. I have attached a
preliminary (incomplete) version of the documentation.

The system is being designed for use in my professional work and by boost
(www.boost.org), an organization developing open-source C++ libraries. It
will be hosted at boost as the Boost Build system.

> 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)

The boost build system handles this. So far, the only customization has been
to the Jambase rules; we haven't had to change Jam's C++ source code. There
are a few changes we anticipate wanting to make, though, mostly for
compatibility with a wider range of platforms.

> 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.

I'm not intimately familiar with the issues of where PDBs need to be located
and exactly how they work. Each toolset supported by the boost build system
has an associated toolset definition file, written in simple Jam code; I'm
hoping that experts on particular toolsets will be able to help me fill in
these details.

> 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?

Hmm, sounds thorny. If you can figure out how you want the MSVC tools to be
invoked so that everything works for you, we can surely get the build system
to invoke them that way... but someone other than me will have to figure out
the toolset-specific stuff.

-Dave