[cairo] [PATCH] Make utilites buildable on modern Linux distro (RHEL-7).
bryce at osg.samsung.com
Fri Mar 6 18:12:46 PST 2015
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
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
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.
More information about the cairo