From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-04 18:45:49
Vladimir Prus wrote:
> Robert Ramey wrote:
> The bad news is that gmon.out is useless. You won't get anyway
> information for any C++ library, and you'll end up with
> vector<something>::operator on top, or some such function.
Hmmm - looking at the gprof output from the serialization library
tests confirms my view that it's a lot more useful than what I had
before - which was nothing.
>> But I wonder is there some bjam magic which can be helpful with this
> The right solution is to run binaries under callgrind, and store
> the output. This is not supported -- you're the first one to ask.
> Note also that profiling the testsuite is not particularly good idea,
> as testsuite are not likely to represent real-world data.
It seemed to me that this would/should be a trivial tweak in
in some Jamfile. I knew that the test executabes are removed after
being run so I suspect that moving the gmon.out file to
the target directory after the test is run would be a trivial
extention - and it would give me a tiny project to around
which to learn a little about bjam - maybe enough to fix
the things in my Jamfile.v2.
After about 4 hours perusing the documentation, jam files,
running little tests I just gave up. Its too hard. Perhaps it
needs a disclaimer that it's only going to be productive for
the smartest developers.
Since I still needed the gmon.out files in their respective
directories I made a small shell script to execute each
executable and mv the gmon.out to the correct directory.
Took me about 15 minutes to write test and execute.
Also another thing intrigues me. By default the tests remove
the executables to save space. I can understand this. But
why just the executables and not the other files such as the
object files. Just curious.
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