On Thu, Jul 14, 2016 at 07:54:59PM +0100, Emil Velikov wrote: > On 14 July 2016 at 17:49, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote: > >> Hi Marius, > >> > >> Just double-checking - this is an i-g-t patch, isn't it ? > >> > >> On 14 July 2016 at 11:39, Marius Vlad <marius.c.vlad@xxxxxxxxx> wrote: > >> > Required by commit 2603b98ca (aubdump: Support softpin bos). > >> > > >> > Signed-off-by: Marius Vlad <marius.c.vlad@xxxxxxxxx> > >> > CC: Kristian Høgsberg Kristensen <kristian.h.kristensen@xxxxxxxxx> > >> > --- > >> > configure.ac | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/configure.ac b/configure.ac > >> > index f05bcb0..ade9756 100644 > >> > --- a/configure.ac > >> > +++ b/configure.ac > >> > @@ -119,7 +119,7 @@ if test "x$GCC" = "xyes"; then > >> > fi > >> > AC_SUBST(ASSEMBLER_WARN_CFLAGS) > >> > > >> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.64 libdrm]) > >> > +PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.68 libdrm]) > >> Yes please. As you do that one can nuke most/all the "define LOCAL_" > >> and "struct local_" (in lib/ioctl_wrappers.h) > >> and replace with with the official symbols. A very nice plus imho ;-) > > > > Please don't. It makes running on older installations even more > > cumbersome. > Slightly confused here: are you against the libdrm_intel bump, or the > removal of the local symbols ? Local symbols. They save a lot of time if you can just get the test you need compiling and not worry about dependencies. One of the basic tenents is that we drop a new kernel into an old userspace and expect to have not broken anything. Being lazy, for smoke testing I just build in situ. > Admittedly sometimes distros don't bother/refuse to update libdrm > which could be an issue in the former case. Although if the package > (with all the definitions) is compulsory, how would that cause an > issue ? The package may not even exist when testing on v.old distro images. It is mostly a major of convenience, but since the work is already done to be independent, removing causes more work. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
