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

[Matěj Cepl]

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?

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.

> 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?

> 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?


> 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