[cairo] Testsuite changes this week
Bryce Harrington
bryce at osg.samsung.com
Wed Sep 17 17:59:56 PDT 2014
On Wed, Sep 17, 2014 at 11:06:17PM +0200, Uli Schlachter wrote:
> Hi,
>
> Am 17.09.2014 um 22:43 schrieb Bryce Harrington:
> > On Tue, Sep 16, 2014 at 09:14:07AM +0200, Uli Schlachter wrote:
> [...]
> >> Something is merging font options wrongly? Why does this code work for
> >> cairo-xlib? I don't know...
> >>
> >> For the xlib backend: Are you running with --enable-xlib-xcb? Aka "are you
> >> testing xlib at all?".
> >
> > Yes. I've attached the script I run, that has the build options I am
> > using. Would appreciate a sanity check.
>
> Nope, you did not.
Whoops. Attached now.
> However, I would suggest you remove --enable-xlib-xcb. There were bugs in that
> glue code, but its way less code than the xlib backend itself and to me it
> sounds like a better idea to include the xlib backend (in your test suite runs.
> This code is actually used in production while configure warns everyone about
> using xlib-xcb.
Alrighty.
> AFAIR this would also get rid of a number of test suite failures (which are
> mostly due to cairo-xcb producing different output than cairo-xlib, I remember
> cases where cairo-xcb matched the image result and cairo-xlib had its own
> reference image. With --enable-xlib-xcb, that will count as a failure.)
Sounds good. Since the results won't be comparable with past runs I'll
reset the numbers.
And since I'm resetting the numbers anyway, I'm going to make a more
extensive change, splitting my testing into three runs each with a
different config - one non-GL, the second with GLX, and third with EGL.
> >> Not much time right now (or in the near future), so can't look too closely into this
> >
> > Thanks, based on Lukas' feedback sounds like we should disable it until
> > folks have time to investigate. I'll push that change today.
>
> Please leave behind a FIXME-comment explaing the "if 0". Thanks for doing this.
Done and pushed.
> > Uli, btw, when you have a few minutes, I'd like to get your quick input
> > on a few of our milestoned bugs that have patches - see:
>
> In general these milestones were pretty much ignored. Someone decides the
> release is "good enough" and does a release.
Yes, totally understandable. Still, I find it useful to boil them down
as part of the release process.
> > https://bugs.freedesktop.org/show_bug.cgi?id=68382
>
> On the "have a few minutes"-front: Not much time in the next two weeks. Deadline
> for my master's thesis.
>
> Your "bug 85688" comment points at a bug that does not exit.
>
> I am not touching bug 74779. Sorry, but that code is enough magic to scare me away.
>
> Uhm, yeah.
>
> > Also, in the interest of getting 1.14 done sooner rather than later, I
> > flagged four bugs I think we could postpone, but would like a second
> > opinion.
>
> The "postpone" category is fine with me per the above description. 54991 can
> just be removed from tracker bugs, 55836 isn't going to happen unless someone
> works on it and that's nothing to be sad about.
>
> Part 1 of 60496 sounds like "that other" bug against cairo-xcb which I don't
> intend to fix any time soon, so likely a case of --enable-xlib-xcb. Part 2 can
> go into the "no idea, wait for someone to figure things out, cairo-win32 is
> broken anyway"-category.
>
> Bug 62606 can be removed from trackers due to NEEDINFO.
Thanks, I'll make these updates.
> > Oh, and did we ever get a firm decision about whether the next
> > release would be numbered as 1.14.0 or 1.12.18?
>
> Someone asked about a new release from the 1.12 branch today. That would
> definitely be 1.12.18. I don't have the time yet and I'd want to double-check
> that the patches in the branch are fine and that nothing useful hides in master.
> I could do that in two weeks.
Sounds good. As we had a number of build fixes on master, would benefit
us to encourage some build testing of the 1.12 branch on Win32, OSX,
Arch, etc. and port whatever fixes are needed there.
> A new release from master should be 1.14.0. It adds new public API (surface
> scaling) and the image scaling patches that are going around still scare me. I'm
> scared enough not to touch this.
Alright, I'll focus on rolling out a 1.14.0 release. I've gotten
positive feedback from Inkscape QA folks that the scaling changes have
solved the problem at hand, so am not so scared. I'm going to work on
fleshing out / improving the downscaling tests in the coming week, but I
don't see that as a blocker.
Bryce
-------------- next part --------------
#!/bin/bash
if [ "${PATH:0:16}" != "/usr/lib/ccache:" ]; then
export PATH="/usr/lib/ccache:$PATH"
fi
export CC=
# Assume we're in the cairogles directory already
if [ -f Makefile ]; then
make clean
fi
./autogen.sh
echo
echo "== Configuring =="
./configure \
--enable-gl --enable-glx --enable-egl \
--enable-test-surfaces \
--enable-xlib-xcb \
--enable-xml \
--enable-gtk-doc
# Lots of build failures:
# --enable-directfb \
# --enable-drm \
# --enable-skia \
export CC=/usr/bin/ccache
make -j32
More information about the cairo
mailing list