Re: [PATCH] Make utilites buildable on modern Linux distro (RHEL-7).
Bryce Harrington <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Mar 07, 2015 at 12:38:34AM +0100, Matěj Cepl wrote: > On 2015-03-06, 22:25 GMT, Bryce Harrington wrote: > > In fact if it were data-only, we could further consider having it broken > > up into several smaller or more focused repositories. Like you say, > > it's rather a beast as it is currently; would be nice to have a subset > > that runs quicker but still gives reasonable coverage. > > Well, there is for example > https://github.com/ssvb/trimmed-cairo-traces and I agree that > generally the collection seems to be a little bit too excessive > for just ordinary QA checking against cairo regressions. > > > At this point you could run the performance tests individually, but > > there is also a perf/cairo-perf-trace.c tool in mainline to run them. > > It looks for *.trace files and runs them all. If we changed this to > > run directly on lzma files (by doing the decompress and csi-bind steps > > within cairo-perf-trace.c), then we can eliminate the Makefile from > > cairo-traces entirely, and usage becomes much simpler. > > Incorporating lzma and csi-bind how? Just fork/exec these > binaries? There's a library interface for lzma, and for csi-bind, well it's just a small wrapper around cairo_script_interpreter_translate_stream() anyway, so you could just call that directly. > Also, what's cairo-perf-micro doing? Does it actually do > anything with the *.trace files? By looking at the C code (did > I say I am very very bad C-programmer?) it seems like it > doesn't. No, cairo-perf-micro actually runs a set of lower level synthetic benchmarks which you can find in the cairo/perf/micro/ directory. Things like drawing bunches of curves and rectangles, etc. All these tests are compiled into the cairo-perf-micro executable, rather than be individually runnable. I believe it's largely self-contained as a result - IOW you should be able to copy it to /usr/bin/ and run it from any other arbitrary location. > > Debian builds those tools and packages them into the 'cairo-perf-utils' > > package. See debian/cairo-perf-utils.* > > So, that makes perd/* tools installed? That would be helpful. > > > Probably the right way to do this on our end would be to add a > > --enable-perf-utils option to configure, which would cause those > > binaries to be built and installed. There's probably other utilities in > > the tree worth making available for installation. > > That is what that patch does, doesn't it? Indeed, it does. > > However, there is a big implication if we do this, that we're promising > > to keep the command line interface and functional behaviors of these > > utilities reasonably stable henceforth. > > Well, I don't see much user interface at all. > > cairo-perf-trace name.trace > > would run it. Anything else? The command line options and (more importantly) the file format. I think ickle mentioned this previously. OTOH, these utils have been in their current state for years now; maybe little harm in just declaring them stable and proceeding. > > Most of the utilities appear to support either command line arguments or > > an environment variable to tell them where to look for *.trace files, or > > where to store test output. The documentation may be sketchy though, so > > you'd need to examine the source code to see how the util can be run. > > $CAIRO_TRACE_DIR seems to work just fine. Doesn’t it? > > > So, a first step would be to improve perf/README with this information. > > man pages would be even better. > > > > Making the scripts themselves use a consistent env variable or command > > line switch for where the *.trace and output directories are would also > > be a simple way to improve the situation here. > > I will take a look. Eventually. > > Matěj Bryce -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo