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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-18 04:07:42

Hi Jürgen,

> On Thursday 18 September 2003 07:33, Vladimir Prus wrote:
> > 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
>
> This is interesting. We've currently installed a "build farm" and are
> using distcc to distribute compilation across several linux machines.
> We now use our old build-system, but it would be great if I could use
> bjam...

Definitely, that's another use case. In fact, in the moment V2 does not play 
nice with distcc --- it passed -x flag to explicitly specify source 
languange, and it causes distcc to use only local compilation. But 
eventually, yes, we'd need distcc support.

> > 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.
>
> This would work for distcc.jam, too. But the laucher will not appear in
> the generated path, right ? But ...
>
> > 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
>
> We've tested purify sometimes ago and from what I know (and Christian
> wrote), purify _changes_ the generated code. So in this case, bjam
> would have to create a different build-variant. And you would need to
> switch it on and off.

Thanks for catching. Yes, we need "purify" feature, with "on" and "off" values 
("off" being the default). And now I realize that purify support can be 
arranges in the same lines as stlport.

1. purify.jam declares global target /purify//purify, which usage requirements 
does all the magic.
2. It also declares "purify" feature, which is made composite.
3. <purify>on expands to <dependency>/purify//purify

> distcc is different, because it simply forwards compilation. Code
> compiled with and without distcc is identical. So, no extra
> build-variant is needed and desired.

All right. Which means <distcc> feature will be marked as "incidental", meaing 
it has no effect on binaries.

> > 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?
>
> Good question. But note that in this case, no extra variant is needed,
> too.

Right. Though this does not solve ordering question.

> > I'm really interested to hear your opinion on the above. This are
> > just first thoughs, so might contain bugs or be suboptimal.
>
> Just my .02 cents.

Thanks, those were quite valuable cents! 

- Volodya