Re: [jamboost] [BBv2] Assistance developing a Purify toolset

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-18 00:33:05

Hi Christopher,
> 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 

bin/gcc/debug/generate_code_test

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

That top-level module might contain

flags top-level LAUNCHER : <launcher> ;

and all modules inheriting from top-level will contain "LAUNCHER" in their 
action bodies.

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
<toolset>msvc-6.5:<launcher>purify
3. Add <dependency>/purify//purify to top-level requirements.

Now, each main target build with msvc-6.5 will have <launcher>purify in the 
properties.

There are some questions left:
1. Is it possible/desirable to turn purify on and off from the command like 
build request, e.g.

bjam purify=on

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.

- Volodya