Boost logo

Boost-Build :

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

 


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