Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Am 07.10.2014 um 15:19 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:13 AM, Christian König deathsim...@vodafone.de wrote:
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König deathsim...@vodafone.de
wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
to
determine where to install the OMX files and ignored $prefix. But Emil
wanted all generated plugins to be installed consistently so he changed
VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be
consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
Would work for me as well, but doesn't sounds like the ideal solution.
Looking into the libomxil-bellagio.pc we have a whole chain of definitions
like:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
toolsdir=${exec_prefix}/bin
pluginsdir=${libdir}/libomxil-bellagio0
Isn't it somehow possible to let pkg-config assume a different $prefix while
evaluating the $pluginsdir variable (I honestly have no idea how pkg-config
works)?
That would solve the problem for OMX and make the behavior consistent again.
Not sure about pkg-config either, but seems like defaulting it to
${libdir}/libomxil-bellagio0 is the right thing then (similarly to
vdpau defaulting to ${libdir}/vdpau). That way you can set --libdir to
/usr/lib/weirdo/place/that/debian/likes and everything will work out
as expected. Right?
Nope, that won't work neither for Ubuntu nor Fedora.
Ubuntu usually sets $libdir to /usr/lib/x86_64-linux-gnu/ but the OMX
dir is /usr/lib/libomxil-bellagio0/. And for Fedora the subdirectory is
named differently than libomxil-bellagio0.
I've checked the pkg-config man page in the meantime, all we need to do
is using --define-variable=prefix=$prefix for OMX.
At least on Ubuntu running pkg-config --variable=pluginsdir
--define-variable=prefix=/foo libomxil-bellagio gives me
/foo/lib/libomxil-bellagio0 which is exactly what we wanted to know.
I'm pretty sure that's the right approach here,
Christian.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Tue, Sep 30, 2014 at 01:33:08 +0100, Emil Velikov wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
volunteer for the following, even if the chances of it happening are zero ?
${libdir} is /usr/lib/x86_64-linux-gnu.
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
to determine where to install the OMX files and ignored $prefix. But
Emil wanted all generated plugins to be installed consistently so he
changed VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be consistent.
Regards,
Christian.
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx and va
?
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
I'm getting this close to just not building vdpau anymore due to
this breakage.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Tue, Oct 7, 2014 at 9:04 AM, Christian König deathsim...@vodafone.de wrote: Am 07.10.2014 um 03:11 schrieb Ilia Mirkin: I'm under the assumption that OMX/etc don't do anything ridiculous. If they do, it's a bug just like this vdpau situation, and should be addressed as such. However addressing them should not preclude vdpau from being fixed. Well, that was the whole point of the change. For OMX you don't have a standardized sub directory where to put the loadable modules, e.g. it's named libomxil-bellagio0 on Ubuntu and completely different on Fedora. So what I did was just to use the $pluginsdir from libomxil-bellagio.pc to determine where to install the OMX files and ignored $prefix. But Emil wanted all generated plugins to be installed consistently so he changed VDPAU to the same behavior as OMX. I'm perfectly fine with either approach, but it should just be consistent. How about just failing the configure if you enable OMX (or anything else we don't know what to do with) but don't specify an install dir? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König deathsim...@vodafone.de wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc to
determine where to install the OMX files and ignored $prefix. But Emil
wanted all generated plugins to be installed consistently so he changed
VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
Would work for me as well, but doesn't sounds like the ideal solution.
Looking into the libomxil-bellagio.pc we have a whole chain of
definitions like:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
toolsdir=${exec_prefix}/bin
pluginsdir=${libdir}/libomxil-bellagio0
Isn't it somehow possible to let pkg-config assume a different $prefix
while evaluating the $pluginsdir variable (I honestly have no idea how
pkg-config works)?
That would solve the problem for OMX and make the behavior consistent again.
Regards,
Christian.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Tue, Oct 7, 2014 at 9:13 AM, Christian König deathsim...@vodafone.de wrote:
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König deathsim...@vodafone.de
wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
to
determine where to install the OMX files and ignored $prefix. But Emil
wanted all generated plugins to be installed consistently so he changed
VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be
consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
Would work for me as well, but doesn't sounds like the ideal solution.
Looking into the libomxil-bellagio.pc we have a whole chain of definitions
like:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
toolsdir=${exec_prefix}/bin
pluginsdir=${libdir}/libomxil-bellagio0
Isn't it somehow possible to let pkg-config assume a different $prefix while
evaluating the $pluginsdir variable (I honestly have no idea how pkg-config
works)?
That would solve the problem for OMX and make the behavior consistent again.
Not sure about pkg-config either, but seems like defaulting it to
${libdir}/libomxil-bellagio0 is the right thing then (similarly to
vdpau defaulting to ${libdir}/vdpau). That way you can set --libdir to
/usr/lib/weirdo/place/that/debian/likes and everything will work out
as expected. Right?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Tue, Oct 7, 2014 at 9:36 AM, Christian König deathsim...@vodafone.de wrote:
Am 07.10.2014 um 15:19 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:13 AM, Christian König deathsim...@vodafone.de
wrote:
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König
deathsim...@vodafone.de
wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
Well, that was the whole point of the change. For OMX you don't have a
standardized sub directory where to put the loadable modules, e.g. it's
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.
So what I did was just to use the $pluginsdir from libomxil-bellagio.pc
to
determine where to install the OMX files and ignored $prefix. But Emil
wanted all generated plugins to be installed consistently so he changed
VDPAU to the same behavior as OMX.
I'm perfectly fine with either approach, but it should just be
consistent.
How about just failing the configure if you enable OMX (or anything
else we don't know what to do with) but don't specify an install dir?
Would work for me as well, but doesn't sounds like the ideal solution.
Looking into the libomxil-bellagio.pc we have a whole chain of
definitions
like:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
toolsdir=${exec_prefix}/bin
pluginsdir=${libdir}/libomxil-bellagio0
Isn't it somehow possible to let pkg-config assume a different $prefix
while
evaluating the $pluginsdir variable (I honestly have no idea how
pkg-config
works)?
That would solve the problem for OMX and make the behavior consistent
again.
Not sure about pkg-config either, but seems like defaulting it to
${libdir}/libomxil-bellagio0 is the right thing then (similarly to
vdpau defaulting to ${libdir}/vdpau). That way you can set --libdir to
/usr/lib/weirdo/place/that/debian/likes and everything will work out
as expected. Right?
Nope, that won't work neither for Ubuntu nor Fedora.
Ubuntu usually sets $libdir to /usr/lib/x86_64-linux-gnu/ but the OMX dir is
/usr/lib/libomxil-bellagio0/. And for Fedora the subdirectory is named
differently than libomxil-bellagio0.
So... Ubuntu sets libdir differently for bellagio than for all their
other packages? That's a little odd. But... do we care? Ubuntu can
have an installation script that deals with their... peculiarities.
Much like we have a --libdir option, it seems reasonable to have a
--omx-plugin-dir or whatever, which Ubuntu and Fedora can set to their
heart's content.
I've checked the pkg-config man page in the meantime, all we need to do is
using --define-variable=prefix=$prefix for OMX.
At least on Ubuntu running pkg-config --variable=pluginsdir
--define-variable=prefix=/foo libomxil-bellagio gives me
/foo/lib/libomxil-bellagio0 which is exactly what we wanted to know.
I'm pretty sure that's the right approach here,
IMO the right approach is for people who do weird things to suffer the
consequences of their weirdness. Of course 'weird' is in the eye of
the beholder, but I think that setting libdir's differently between
packages fits nicely into that definition. In this case, it seems like
feeding the libdir in if it's specified is the correct thing, which
would yield the same result as just defauting the way I had suggested
without involving pkg-config.
However I'm happy to accept any approach that results in a
./configure --prefix=/path/to/dir
make install
not installing to a directory outside of the prefix. That's my #1
concern. My personal inclination, however, would be to just default it
to ${libdir}/whatever.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de
wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx and va
?
-Emil
It seems reasonable to
make vdpau work sanely (i.e. revert the commit that breaks my, and I
presume many others', setup by attempt to break out of the specified
prefix) and let someone else work out the omx stuff. I don't think the
revert should be held up based on the lack of some additional change
-- it never should have gone in in the first place.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Sun, 2014-09-28 at 16:13 -0400, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 4:09 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 28/09/14 20:08, Emil Velikov wrote:
On 28/09/14 19:04, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
[snip]
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 ?
Had this idea, but I'm not too trilled about it:
Default = blank, and error out if the user did not set it. The error
message will state how to get it of course :)
This approach is not ideal but in a way it covers the all must adhere
prefix and prevents the case of xx reports on the topic vdpau/omx is
broken.
Thoughts ?
What was wrong with the thing we did before that worked fine for
everyone in all cases? Use ${prefix}/lib/vdpau, allow people to
override if they want something funky?
this might be a stupid question, but why not just replace system prefix
with specified prefix in --variable=moduledir ?
that way it installs to the correct directory if you don't specify
prefix and remains contained within prefix if you do.
Moreover, it makes your ${prefix} mimic your distro layout which is imo
desirable.
jan
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Jan Vesely jan.ves...@rutgers.edu
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de
wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx and
va ?
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
I'm getting this close to just not building vdpau anymore due to
this breakage.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Mon, Oct 6, 2014 at 9:11 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de
wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx and
va ?
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
I'm getting this close to just not building vdpau anymore due to
this breakage.
What I'm really perplexed by, by the way, is the lack of people
jumping in to R-b this. There have been a few weak yes, this is bad
but no R-b. I would have thought that installing outside of the prefix
is such an obvious no-no that a change introducing that would just get
insta-reverted. But perhaps I'm wrong, and people do expect random
system files to get overwritten when they run 'make install' despite
having explicitly said it should install somewhere else, and I should
just crawl back into my hole instead of trying to get the kids to stop
playing on my damn lawn.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Is it missing an R-b?
Reviewed-by: Dave Airlie airl...@redhat.com
can you just push it now?
Dave.
On 7 October 2014 11:36, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Oct 6, 2014 at 9:11 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de
wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov
emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for
the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX.
Do I take that you've missed that my volunteer request covers vdpau, omx
and va ?
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation, and should be
addressed as such. However addressing them should not preclude vdpau
from being fixed.
I'm getting this close to just not building vdpau anymore due to
this breakage.
What I'm really perplexed by, by the way, is the lack of people
jumping in to R-b this. There have been a few weak yes, this is bad
but no R-b. I would have thought that installing outside of the prefix
is such an obvious no-no that a change introducing that would just get
insta-reverted. But perhaps I'm wrong, and people do expect random
system files to get overwritten when they run 'make install' despite
having explicitly said it should install somewhere else, and I should
just crawl back into my hole instead of trying to get the kids to stop
playing on my damn lawn.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
a
volunteer for the following, even if the chances of it happening are
zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Unfortunately I don't know anything about OMX. It seems reasonable to
make vdpau work sanely (i.e. revert the commit that breaks my, and I
presume many others', setup by attempt to break out of the specified
prefix) and let someone else work out the omx stuff. I don't think the
revert should be held up based on the lack of some additional change
-- it never should have gone in in the first place.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
volunteer for the following, even if the chances of it happening are zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
You need to implement the same for the OMX target as well, since the
intention was to get a consistent behavior.
Regards,
Christian.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
volunteer for the following, even if the chances of it happening are zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
Pretty much everyone that reports a bug/send an email to the ML/posts a
big and flashy review along the lines of vdpau/omx/va is
useless/broken like YKW.
The numbers/reports will be low (if any), but the encounters are likely
to be quite interesting.
I'm more than happy to enlighten people as to why what they're doing
is wrong. I guess this patch is good then?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
volunteer for the following, even if the chances of it happening are zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
Guide who? The maintainers? Sure, I'll happily help them out.
There are basically a few categories of users:
(a) People whose job it is to create distro package definitions. These
people usually know what they're doing, so pretty much whatever we do,
they'll be able to work something out. If they're used to setting
weirdo paths, they'll keep setting them here. No problem.
(b) People who do a LFS-style setup and want to install on their
system. They'll be generally fine with the defaults (/usr, etc), and
it will work for them here.
(c) People who don't want to mess up their system install but still
want to futz with other mesa versions (this includes me). Prefix will
now do the right thing again.
(d) People who use something akin to stow. Again, they want things all
inside the prefix.
And then there are the masses of people who don't really know what
they're doing, but they found some blog which had some stuff written
in it. It didn't quite work, but when randomly combined with things in
another blog they found from 6 years ago, something worked a little
bit. There's just not a whole lot we'll ever be able to do to deter
such users from making terrible mistakes.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Sun, 28 Sep 2014 13:00:47 -0400 Ilia Mirkin imir...@alum.mit.edu 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. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: Christian König deathsim...@vodafone.de Cc: Alexandre Demers alexandre.f.dem...@gmail.com Cc: Matt Turner matts...@gmail.com Cc: Emil Velikov emil.l.veli...@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.) Setting a prefix should cause things to be installed into that prefix. This is how every other autoconf-using package behaves. 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. configure.ac | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) Hi, so do I understand correctly, that assuming there is a system libvdpau installed but not another one in the $prefix, then Emil wants the system libvdpau to automatically discover the backends from $prefix? (Not literally, but with an equivalent effect.) If so, I would find that strange. A system library finding modules automatically from inside a $prefix is certainly unexpected. One uses a separate $prefix to exactly avoid that. Yet, from the IRC and this discussion here, it sounds like the reason to make the original patch, except it's just the other way around: cannot make system libvdpau go look in arbitrary $prefixes, so install into the system paths instead. If that was not the reason, then I completely missed it, sorry. FWIW, I agree with Ilia: 'make install' should never attempt to write outside of the given $prefix (or DESTDIR, whatwasit). It didn't even cross my mind before that some build might actually try writing to system paths regardless (and then simply fail half-way through installing, leaving me with a broken $prefix). Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
Am 28.09.2014 um 22:13 schrieb Ilia Mirkin:
On Sun, Sep 28, 2014 at 4:09 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 28/09/14 20:08, Emil Velikov wrote:
On 28/09/14 19:04, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
[snip]
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 ?
Had this idea, but I'm not too trilled about it:
Default = blank, and error out if the user did not set it. The error
message will state how to get it of course :)
This approach is not ideal but in a way it covers the all must adhere
prefix and prevents the case of xx reports on the topic vdpau/omx is
broken.
Thoughts ?
What was wrong with the thing we did before that worked fine for
everyone in all cases? Use ${prefix}/lib/vdpau, allow people to
override if they want something funky?
The issue with that is the same as with OMX, it just doesn't work for
all distributions.
Debian/Ubuntu for example installs things into
/usr/lib/x86_64-linux-gnu/vdpau/ and that's exactly what moduledir in
vdpau.pc is pointing to. We could do something like ${libdir}/vdpau
instead, but I think that is similar broken since it assumes that the
module directory is named vdpau.
How about we just use whatever is defined in the pkg-config files as
long as no prefix is given to configure and fallback to the hardcoded
names when the user specifies it manually?
Regards,
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
So all in all we have the following: Some distributions/people choose odd location of the modules. Which can lead to the system (vdpau/omx) looking at the wrong place for the backends, i.e. not working. One can consider that there is no way to override the module location at runtime. So we either - Try to be smart and auto-detect it at configure time, causing a violation of the --prefix , or - Choose a sane default, and let the packager worry about the broken setup. Imho the do the auto-detection only when the prefix is empty approach is useless as virtually everyone sets the prefix. As mentioned earlier, I expect the latter will cause more issues than the former thus why I've went with the patch. On the other hand the majority is inclined to do the correct thing, which means breaking some builds. How many volunteers do we have that will guide Debian/Ubuntu/other to do the correct thing ? If we have at least one, I will be OK with reverting the patch. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Mon, Sep 29, 2014 at 1:43 AM, Christian König
deathsim...@vodafone.de wrote:
Debian/Ubuntu for example installs things into
/usr/lib/x86_64-linux-gnu/vdpau/ and that's exactly what moduledir in
vdpau.pc is pointing to. We could do something like ${libdir}/vdpau instead,
but I think that is similar broken since it assumes that the module
directory is named vdpau.
That only sounds as broken as installing GL headers in a directory
named GL/. What am I missing?
(Installing to ${libdir}/vdpau sounds right to me)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So all in all we have the following:
Some distributions/people choose odd location of the modules. Which
can lead to the system (vdpau/omx) looking at the wrong place for the
backends, i.e. not working. One can consider that there is no way to
override the module location at runtime.
Do we have more specifics? If they're doing something stupid and it
breaks, they typically get to keep the pieces.
Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
Hmm I was under the impression that ${libdir} and
/usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
volunteer for the following, even if the chances of it happening are zero ?
On 29/09/14 17:16, Emil Velikov wrote:
[...]
How many volunteers do we have that will guide Debian/Ubuntu/other to
do the correct thing ? If we have at least one, I will be OK with
reverting the patch.
-Emil
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
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.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: Christian König deathsim...@vodafone.de
Cc: Alexandre Demers alexandre.f.dem...@gmail.com
Cc: Matt Turner matts...@gmail.com
Cc: Emil Velikov emil.l.veli...@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.)
Setting a prefix should cause things to be installed into that prefix. This is
how every other autoconf-using package behaves.
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.
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])
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
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.
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 imir...@alum.mit.edu
Cc: Christian König deathsim...@vodafone.de
Cc: Alexandre Demers alexandre.f.dem...@gmail.com
Cc: Matt Turner matts...@gmail.com
Cc: Emil Velikov emil.l.veli...@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.
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.
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])
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@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 :)
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 imir...@alum.mit.edu
Cc: Christian König deathsim...@vodafone.de
Cc: Alexandre Demers alexandre.f.dem...@gmail.com
Cc: Matt Turner matts...@gmail.com
Cc: Emil Velikov emil.l.veli...@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.
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.
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, 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.
-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])
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 28/09/14 19:04, Ilia Mirkin wrote: On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@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 imir...@alum.mit.edu Cc: Christian König deathsim...@vodafone.de Cc: Alexandre Demers alexandre.f.dem...@gmail.com Cc: Matt Turner matts...@gmail.com Cc: Emil Velikov emil.l.veli...@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`@:@])],
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 29 September 2014 05:08, Emil Velikov emil.l.veli...@gmail.com wrote: On 28/09/14 19:04, Ilia Mirkin wrote: On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@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. libva-intel-driver is probably not an example of anything you want to do. 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 ? distros can keep up, don't install outside --prefix is a rule we should stick to,. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 28/09/14 20:08, Emil Velikov wrote: On 28/09/14 19:04, Ilia Mirkin wrote: On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com wrote: [snip] 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 ? Had this idea, but I'm not too trilled about it: Default = blank, and error out if the user did not set it. The error message will state how to get it of course :) This approach is not ideal but in a way it covers the all must adhere prefix and prevents the case of xx reports on the topic vdpau/omx is broken. Thoughts ? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On Sun, Sep 28, 2014 at 4:09 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 28/09/14 20:08, Emil Velikov wrote:
On 28/09/14 19:04, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
[snip]
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 ?
Had this idea, but I'm not too trilled about it:
Default = blank, and error out if the user did not set it. The error
message will state how to get it of course :)
This approach is not ideal but in a way it covers the all must adhere
prefix and prevents the case of xx reports on the topic vdpau/omx is
broken.
Thoughts ?
What was wrong with the thing we did before that worked fine for
everyone in all cases? Use ${prefix}/lib/vdpau, allow people to
override if they want something funky?
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers
On 29 September 2014 06:13, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sun, Sep 28, 2014 at 4:09 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 28/09/14 20:08, Emil Velikov wrote:
On 28/09/14 19:04, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
[snip]
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 ?
Had this idea, but I'm not too trilled about it:
Default = blank, and error out if the user did not set it. The error
message will state how to get it of course :)
This approach is not ideal but in a way it covers the all must adhere
prefix and prevents the case of xx reports on the topic vdpau/omx is
broken.
Thoughts ?
What was wrong with the thing we did before that worked fine for
everyone in all cases? Use ${prefix}/lib/vdpau, allow people to
override if they want something funky?
use ${libdir}/vdpau as default.
or whatever vdpau uses as a default.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
