|
From: Nicholas N. <nj...@cs...> - 2005-07-01 21:01:44
|
On Thu, 30 Jun 2005, Josef Weidendorfer wrote: > I thought the idea was to statically link the tool with valgrind at build > time. What else would a RPM have to provide from core valgrind other than the > built executable? In this sense, there is no own copy in the RPM. > Am I missing something here? No, I was confused. >> -- there's no danger of someone having a new Valgrind which >> doesn't match an old Callgrind. > > Given that the tool API version checking is working correctly -- which AFAIK > always was the case for stable releases -- this was prevented successfully. Sure, it never went wrong, but it could have. With the static linking proposal there's nothing to go wrong. >> 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. > > Why? You do not need to do any check at runtime, but a check for the tool API > version at build time is still better than relying an exact valgrind release > numbers. The API still would exist - and major versions still make sense. I wasn't thinking in terms of exact release numbers. I was just thinking that if the tool and core compiled together, they matched ok. >> 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. > > I do not understand this. What is the difference between one executable for > multiple tools and a separate for each? You could have one executable and > hardlinks to this one, and run the tool depending on argv[0]. If the tools that come with the Valgrind distribution are all in one executable, but Callgrind comes in a different executable, there is a lack of consistency. >> 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. > > The issue here is that you again introduce some kind of dependency of a > "standalone" callgrind installation to an installed valgrind: the minimal > stage1. So why such a minimal stage1 at all? If we preserve the --tool option and want to use it for both internal and external tools, a minimal stage1 seems unavoidable. Overall, I think the static linking idea is sound. There are a couple of minor details to resolve, such as how exactly the chosen tool should get invoked (via --tool? via some kind of symlink or hardlink?) but they are not a big problem. N |