[cairo] [PATCH] Make utilites buildable on modern Linux distro (RHEL-7).

[Bryce Harrington]

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