|
From: Josef W. <Jos...@gm...> - 2006-09-07 12:11:27
|
On Thursday 07 September 2006 09:49, Nicholas Nethercote wrote: > On Thu, 7 Sep 2006, Josef Weidendorfer wrote: > > > I think it would be better for experimental tools to first live outside > > of VGs core code base; we should provide an example "external VG tool > > package". I did this a long time with callgrind, and it was > > working quite well (with the exception of biarch). > > I disagree. This was the approach we took with Callgrind for a long time, > but in hindsight I think it was the wrong one. Presence in the > distribution gives a tool much more exposure, and I think it makes it more > likely that new tools will become popular and good. Just thinking about pros/contras for external VG tools. Currently, a VG tool author can distribute his/her tool by (1) convince VG core authors to include it into VG package (2) hack a VG source distribution to include his/her tool, thus distributing a customized Valgrind package (3) distribute an external VG tool package IMHO, (2) is only useful in the development process of a tool, but not very good for distribution because of installation conflicts with the official VG package. (2) is of course the only way when starting a port to another platform. For the tool author, (3) does have some benefits * No need to convince VG core authors to include it into VG package * Allows for very loose development, independent from VG release cycles * Allows for small source package, dependent on an official VG installation in the user system * Allows the tool to be packed with visualization/post processing/... applications, which could be a problem integrating into VG source (eg. QT/GTK dependency) However, when the author can convince VG core authors to include it into VG package, (1) is nice for a number of reasons: * Exposure * Possibly better direct help from VG authors * Possibly less bugs because more eyes scan the code * No version mismatch possible * Better influence in additions to core/tool API * Simple integration into existing regression test suite, and automatic testing overnight on different platforms * Easy integration of documentation The last to items were actually a problem with callgrind before. Now, it is questionable whether we want to support (3) at all in the future, which really needs a check whether all header files, needed libraries, correct *.pc file are installed. IMHO, it is worth it because (3) lowers the barrier for new tool authors by giving them choice. And exposure also is possible by naming external tools on the web site. Josef |