[Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"

[Emil Velikov]

On 28/09/14 19:04, Ilia Mirkin wrote:
> On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 28/09/14 18:00, Ilia Mirkin wrote:
>>> This reverts commit bbe6f7f865cd4316b5f885507ee0b128a20686eb.
>>>
>>> This change broke the usual assumption that setting a prefix will cause
>>> files to be installed into that prefix. Restore that assumption before
>>> people's system installs are accidentally overwritten, and everyone
>>> starts having to add a --with-libvdpau-dir as a hack to work around this.
>>>
>> That assumption was broken long time ago. Mesa is _not_ the only package
>> to do so.
> 
> I honestly can't think of another package that uses autoconf and
> doesn't respect --prefix. You may be right that such a package may
> exist, but if you point it out, I'll just file a bug with them asking
> them to fix it :)
> 
libva-intel-driver is a nice example. I've come across another 5+ a
couple of weeks ago but did not bother writing them down. Doubt that I
will look into this obscurity any time soon, but I'll make a note just
in case I change my mind.

>> Additionally the change is documented, and if no-one is bothered with
>> check it's their own problem as things break. We all have assumptions,
>> but we occasionally check if they are correct.
>>
>>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>>> Cc: Christian König <deathsimple at vodafone.de>
>>> Cc: Alexandre Demers <alexandre.f.demers at gmail.com>
>>> Cc: Matt Turner <mattst88 at gmail.com>
>>> Cc: Emil Velikov <emil.l.velikov at gmail.com>
>>> ---
>>>
>>> Emil and I had a discussion about this on IRC but he didn't seem to
>>> agree. However I think that this behavior is as broken as opening up
>>> ld.so.conf, grabbing the first dir from that and using that as the
>>> installation libdir. (Which I think everyone can agree is ridiculous.)
>>>
>> Indeed the ld.so.conf example is ridiculous, but this is a completely
>> different thing. Those backends are used by the libvdapu library, thus
>> one must adhere with it - i.e. the variable in pkg-config.
>>
>>> Setting a prefix should cause things to be installed into that prefix. This is
>>> how every other autoconf-using package behaves.
>>>
>> I seriously doubt that you've been through every autoconf-using package
>> so your last statement is full of air.
> 
> Certainly not every, you're right. However I did, for a fairly long
> time, build all of my system packages by hand, so I have a pretty good
> idea of how most of the software I've ever used builds. (Or at least
> how it built back when I did that.)
> 
>>
>>> As a side-note, using --with-module-dir as an installation destination is a
>>> little crazy, but... I don't have the energy to fight that one.
>>>
>> Blame that one on the libvdpau people. They chose to expose this feature
>> to the user.
> 
> Blame how libvdpau works? Sure. I think it's odd, but... I kinda see
> why they did it that way.
> 
Indeed the point they've set is reasonable. But that makes mesa's life hard.

> This, however, has nothing to do with mesa. When I set --prefix,
> that's saying "hey, install here". Not "hey, install here for most
> things, but actually overwrite my system install for other things".
> 
The point is if we are to revert this, we have to nuke the equivalent
omx and va ones. Afaics there is no middle ground - either we keep the
commit or add some default and hope that distros and anyone building
mesa will bother correcting their config. Are you volunteering to hold
everyone's hand during the transition ?

So essentially I have chosen the lesser evil here :)

> Something else to think about -- not everyone building mesa plans to
> use the resulting libvdpau_$driver.so, however they might not build
> with --disable-vdpau. But they do expect the GL install to go into
> their prefix. Since vdpau is on by default,
vdpau seems to be set to "auto"(enable if libvdpau is installed). If
they are building GL they are rather unlikely to think/have the
pre-requisite.

> they'll get a failure on
> make install if they're not root, or worse, overwrite their system
> install if they carelessly run "sudo make install" or equivalent.
> 
The argument of "they might hurt themselves if not careful so we' wrap
everything in bubble-wrap" sounds a bit too much imho. Wrap the person
(point/guide them how to educate themselves) rather than trying to extra
fool-proof everything.

Emil

>   -ilia
> 
>>
>> Thanks
>> Emil
>>>  configure.ac | 11 +++--------
>>>  1 file changed, 3 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 51f6c66..84af6b4 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -1768,17 +1768,12 @@ if test "x$enable_gallium_tests" = xyes; then
>>>  fi
>>>  AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test "x$enable_gallium_tests" = xyes)
>>>
>>> -VDPAU_LIB_INSTALL_DIR_DEFAULT=''
>>> -if test "x$enable_vdpau" = xyes; then
>>> -    VDPAU_LIB_INSTALL_DIR_DEFAULT=`$PKG_CONFIG --variable=moduledir vdpau`
>>> -fi
>>> -
>>>  dnl Directory for VDPAU libs
>>>  AC_ARG_WITH([vdpau-libdir],
>>>      [AS_HELP_STRING([--with-vdpau-libdir=DIR],
>>> -        [directory for the VDPAU libraries @<:@default=`pkg-config --variable=moduledir vdpau`@:>@])],
>>> +        [directory for the VDPAU libraries @<:@default=${libdir}/vdpau@:>@])],
>>>      [VDPAU_LIB_INSTALL_DIR="$withval"],
>>> -    [VDPAU_LIB_INSTALL_DIR="$VDPAU_LIB_INSTALL_DIR_DEFAULT"])
>>> +    [VDPAU_LIB_INSTALL_DIR='${libdir}/vdpau'])
>>>  AC_SUBST([VDPAU_LIB_INSTALL_DIR])
>>>
>>>  OMX_LIB_INSTALL_DIR_DEFAULT=''
>>> @@ -1788,7 +1783,7 @@ fi
>>>
>>>  AC_ARG_WITH([omx-libdir],
>>>      [AS_HELP_STRING([--with-omx-libdir=DIR],
>>> -        [directory for the OMX libraries @<:@default=`pkg-config --variable=pluginsdir libomxil-bellagio`@:>@])],
>>> +        [directory for the OMX libraries])],
>>>      [OMX_LIB_INSTALL_DIR="$withval"],
>>>      [OMX_LIB_INSTALL_DIR="$OMX_LIB_INSTALL_DIR_DEFAULT"])
>>>  AC_SUBST([OMX_LIB_INSTALL_DIR])
>>>
>>