|
From: Nicholas N. <n.n...@gm...> - 2023-03-21 23:23:08
|
I have merged the new version of `cg_annotate`: https://sourceware.org/git/?p=valgrind.git;a=commit;h=4650b7949ae3a41326e52ae454a9202493c41444 Nick On Fri, 17 Mar 2023 at 16:24, Nicholas Nethercote <n.n...@gm...> wrote: > I have finished the rewrite. I am happy with the new code, it is much > better than the old code. You can see it at > https://bugs.kde.org/show_bug.cgi?id=467472. I plan to merge it by the > end of next week, and I am happy to hear any suggestions. > > I also have some good news about the `cg_annotate.in`/`cg_annotate` > split. I learned that you can generate the latter from the former very > quickly with `config.status cachegrind/cg_annotate.in`. Also, this can be > done automatically from some make targets. So I ended up creating a new > make target `make ann` that can be run within the `cachegrind` directory. > It runs the various Python formatters, type-checkers, and linters I am > using on `cg_annotate.in` and then generates `cg_annotate`. It's a > one-step "build" command that runs quickly, which is great. > > Nick > > On Wed, 15 Mar 2023 at 06:15, Nicholas Nethercote <n.n...@gm...> > wrote: > >> On Sun, 12 Mar 2023 at 23:01, Paul Floyd <pj...@wa...> wrote: >> >>> >>> The only think I can think of to get the version is to use something like >>> >>> pkg-config --modversion valgrind >>> >> >> Thanks for the suggestion. Unfortunately this could cause misleading >> results. E.g. if I have Valgrind installed on my system but I also have a >> development version, when I run the development version of `cg_annotate >> --version` it will claim to be the installed version. I think the `@VERSION@` >> junk is unavoidable. >> >> Nick >> > |