[cairo] [PATCH] Make utilites buildable on modern Linux distro (RHEL-7).
mcepl at cepl.eu
Fri Mar 6 15:38:34 PST 2015
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
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
> 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.
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.
More information about the cairo