|
From: Nicholas N. <nj...@cs...> - 2005-06-30 03:54:08
|
On Thu, 30 Jun 2005, Josef Weidendorfer wrote:
> Linking with valgrind at build time would make RPMs independent, i.e. a
> callgrind installation could exist without valgrind at all or with another
> valgrind release. Similar, currently I am forced to install into the same
> prefix, as valgrind has to find the tool.
That's a good point. I was assuming that Callgrind would have to link
with the already installed Valgrind, but it can have its own copy in the
RPM.
This would give you more independence from the main Valgrind releases,
because you don't necessarily have to update Callgrind when a new Valgrind
is released -- there's no danger of someone having a new Valgrind which
doesn't match an old Callgrind. (Although if the new Valgrind had a new
feature that you wanted, you'd have to rebuild and release a new Callgrind
to take advantage of it.)
We also wouldn't have to worry about having a version number for the
core/tool interface any more, which is nice -- one fewer thing to get
wrong.
>> Alternatively, adjust the core/tool interface so that multiple
>> tools can be linked into the core all at once. This sounds
>> attractive, and could save disk space.
>
> For external tools you still have to provide the library to link against.
> I.e. each external tools would get its own executable. As I am used to install
> my wrapper script ("callgrind"), which would become the executable, AFAICS it
> would not make a big difference.
It would be more consistent to build every tool into a separate
executable, so that internal tools and external tools can be treated the
same way.
It would make sense to have a minimal "stage1" which just looks for the
--tool option and invokes the appropriate executable. This could even
work for external tools if they were installed in the same place. But
Josef could still use his "callgrind" wrapper script.
After Josef's good comments, and with Greg saying that this will make
things easier on MacOS, I'm all in favour of this idea.
N
|