From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-18 00:33:05
> One of the tools that our developers depend on for debugging is
> IBM/Rational Purify which, for those who aren't familiar, is a tool that
> adds code into an executable to detect memory leaks, freed or
> uninitialized memory reads, and other sometimes hard to detect
> programming errors.
> The typical usage of purify is to add it to the front of the normal
> compilation command line, so if my normal build script would execute:
> CC -c -o foo.o foo.cpp
> CC -o bar foo.o
> Then to compile under purify would look like:
> purify CC -c -o foo.cpp
> purify CC -o bar foo.o
This demand is similiar to what I wanted. As you probably know, V2 has
'unit-test' rule, which builds and runs an executable. I'd like to use
valgrind, which has the same purpose as purify and must be prepended to run
command. I.e. instead of
the command line should be
valgrind --gdb-attach=yes bin/gcc/debug/generate_code_test
> I'd like to develop a "purify.jam" toolset to implement this behavior,
> but I'm not exactly sure where to start. I envision a usage like:
> # user-config.jam
> # Set up the default toolsets
> using gcc ;
> using msvc : 6.5 : C:/msvc6 ;
> using msvc : 7.0 : C:/msvc7 ;
> # Purify might only be supported under one version
> using purify : msvc-6.5 ;
> I'd like it cover all the supported toolsets in case we decide to switch
> from our current compiler (Sun CC), but there currently isn't an
> established variable or feature that they all share that I can override.
> Many toolsets (including my own sun.jam) hardcode the name of the
> compiler executable in the "actions", making it difficult to extend.
The solution I had in mind was to intoduce new 'launcher' feature, which will
specify command which will be prepended, verbatim, to command lines.
Never designed that in detail, though...
> I've been thinking about the usefulness of introducing a "compiler"
> module that would extend toolset, add some common features and hooks for
> extension, and then specific toolset modules (those that are compilers)
> would extend from the compiler toolset. This would provide a standard
> set of subfeatures that could then be modified by a purify toolset.
That would be nice solution. But note that it would not apply to 'unit-test'.
So probably we need one 'top-level' toolset module from which everything will
That top-level module might contain
flags top-level LAUNCHER : <launcher> ;
and all modules inheriting from top-level will contain "LAUNCHER" in their
What is left is a mechanism to get right <launcher> property. We can use the
same trick as with Qt support
1. Declare, in 'purify.jam', a global target /purify//purify
2. Set usage requirements for that target to
3. Add <dependency>/purify//purify to top-level requirements.
Now, each main target build with msvc-6.5 will have <launcher>purify in the
There are some questions left:
1. Is it possible/desirable to turn purify on and off from the command like
build request, e.g.
2. What is someone implements other module which uses 'launcher' feature. Say,
I want to measure time compile commands take. The "/usr/bin/time" should be
prepended to each command. If purify is used as well, "/usr/bin/time" must be
prepended before "purify". But how?
I'm really interested to hear your opinion on the above. This are just first
thoughs, so might contain bugs or be suboptimal.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk