On Thursday 15 November 2007, Nicholas Nethercote wrote:
> I didn't really follow that, but it seems like Callgrind produces multiple
> output files. They all have a common prefix, and then each one has a
> different suffix. When it comes to processing them, presumably you give
> callgrind_annotate/KCachegrind the prefix, and then they can find all the
> extra files because they know what the suffixes look like.
Yes, that's right in the case of KCachegrind.
I assume there could be other tools in the future which produce multiple
output files. It is reasonable to expect that they all will be fine
with a user settable prefix part and a tool controlled suffix.
> In other words, it makes sense for a user to specify the prefix, but not the
> suffix, because the processing tools depend on them having a particular
> form.
>
> If I'm right, then I think we only need:
>
> %p process id
> %q{QUAL} environment variable contents
>
> %T for toolname isn't necessary, nor are %t or %c because they're not
> controllable by the user.
Hm. %t could make sense with a tool which has an output per thread.
But as there currently is no such tool, there is no need.
(for callgrind, the thread is part of the suffix which the user does not
have the need to control, so there is no need for %t there, too).
> Overall, we'd have a --log-file option for normal Valgrind output (ie. what
> normally goes to stderr), and then for each tool that writes an output file
> (Cachegrind, Callgrind, Massif) there would be an option like --massif-file.
> In the Callgrind case it would be --callgrind-file-prefix.
Do we really want the tool name in the option? I would vote for one global
option "--output-file=..." to specify an output file name/pattern, and the tool
is free to add suffixes. This makes it easier for the user to remember
* the option name and
* the fact that this option allows for pattern specification.
I currently have the "--base=<prefix>" option in callgrind which does _not_
allow
for patterns. I will deprecate it, but should support it for some time for
backwards compatibility. I think it really would confuse the user if I
additionally
provide a "--callgrind-file-prefix" which allows for patterns...
Josef
>
> Does this make sense?
>
> Nick
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
