<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Mon, May 4, 2015 at 12:11 PM, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Mon, May 4, 2015 at 12:47 PM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote: > On Mon, May 04, 2015 at 10:13:19AM -0400, Ilia Mirkin wrote: >> On Mon, May 4, 2015 at 10:04 AM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote: >> > On Sat, May 02, 2015 at 01:31:41PM -0400, Ilia Mirkin wrote: >> >> On Sat, May 2, 2015 at 1:19 PM, EdB <<a href="mailto:edb%2Bmesa@sigluy.net">edb+mesa@sigluy.net</a>> wrote: >> >> > The standard ICD file path is /etc/OpenCL/vendor/. >> >> > However it doesn't fit well with custom build. >> >> > This option allow ICD vendor file installation path override >> >> > --- >> >> > <a href="http://configure.ac" target="_blank">configure.ac</a> | 6 ++++++ >> >> > src/gallium/targets/opencl/Makefile.am | 2 +- >> >> > 2 files changed, 7 insertions(+), 1 deletion(-) >> >> > >> >> > diff --git a/<a href="http://configure.ac" target="_blank">configure.ac</a> b/<a href="http://configure.ac" target="_blank">configure.ac</a> >> >> > index 095e23e..bf08d76 100644 >> >> > --- a/<a href="http://configure.ac" target="_blank">configure.ac</a> >> >> > +++ b/<a href="http://configure.ac" target="_blank">configure.ac</a> >> >> > @@ -2005,6 +2005,12 @@ AC_ARG_WITH([d3d-libdir], >> >> > [D3D_DRIVER_INSTALL_DIR="$withval"], >> >> > [D3D_DRIVER_INSTALL_DIR="${libdir}/d3d"]) >> >> > AC_SUBST([D3D_DRIVER_INSTALL_DIR]) >> >> > +AC_ARG_WITH([icd-file-dir], >> >> > + [AS_HELP_STRING([--with-icd-file-dir=DIR], >> >> > + [directory for the OpenCL ICD vendor file @<:@/etc/OpenCL/vendors@:>@])], >> >> > + [ICD_FILE_INSTALL_DIR="$withval"], >> >> > + [ICD_FILE_INSTALL_DIR="/etc/OpenCL/vendors"]) >> >> >> >> What about making this default to ${sysconfdir}/OpenCL/vendors ? That >> >> way using --prefix should auto-make it go into the prefix instead of >> >> unexpectedly installing things outside of the specified prefix? That >> >> way a distro build which specifies --sysconfdir as /etc will get it in >> >> the right place, while by default it'll go into /usr/local/etc and a >> >> user can override the icd loader's default behaviour with >> >> OPENCL_VENDOR_PATH? >> >> >> > >> > I would prefer not to make this the default behavior, because it violates the spec >> > and there could potentially be multiple icd implementations, which may or may not have >> > the overrides. >> > >> > I think the best solution would be to rename the option to something like >> > --enable-ocl-icd-respect-prefix (suggestions for other names encouraged). >> > and have the option enable the behavior that Ilia is describing. >> > >> > This will give distros and advanced users a way to setup their system >> > the way they want. >> >> It's just a very anti-autoconf thing to do to have "make install" fail >> by default unless you specify some "hey, i actually want make install >> to work" option. >> >> I think it's crazy to expect that, by default, people will want to >> write over their system installs, and having things go outside of the >> specified --prefix is very surprising (unless you force some other >> option). And asking the user to run "make install" as root is even >> crazier. >> > > My expectation is that, by default, when people specify --enable-opencl-icd > they want an implementation that conforms to the specification. > Unfortunately, this means installing icd files to /etc. </div></div>Oh, does this only happen when I supply some option? I.e. if I just do ./configure --prefix=... it'll still work, I have to do --enable-opencl-icd and only *then* does it install the other thing? That might be more acceptable, although still not really. > > There is no good solution here, but I'd rather have users specify a flag > to get a sane build system, than requiring them to set a flag and set > an environment variable just to get working OpenCL with the ICD loader. I know exceedingly little about OpenCL. I'm just coming at this from a generic "build shouldn't try to install things outside the prefix" perspective. Make install shouldn't fail, and users shouldn't be tempted into accidentally overwriting their system installs even though they set a prefix but then foolishly ran 'sudo make install'. Autoconf is a pretty common build helper, nearly every sane package with a unix build target uses it, and I think people are used to how it works. One of the cool things is that you can do "./configure --prefix=/home/user/install; make install" and expect it to work (as in, things landing in /home/user/install/..., not in /). Or perhaps you use a system like 'stow' which takes care of all the symlinking/etc and allows you to easily have multiple versions of the same software. Having things go outside of the configured directories goes against the autoconf standard... perhaps it'd be OK if you added some giant warning at the end of configure output saying "DANGER DANGER DANGER will do unexpected things by default!". > >> I guess I haven't hit this yet because there's no OpenCL support in >> nouveau or freedreno, but I made the same stink about vdpau when Emil >> tried to make it install to some system location by default. At least >> a few people seemed to agree with me back then... >> > > Does the vdpau spec also require installation to a specific system director > (e.g. /etc/) ? The vdpau loader (libvdpau) loads from a fixed (and arbitrarily configurable at build-time, and practically speaking set differently on different distributions) library directory, much like (the mesa) libGL does. However there's (now) a VDPAU_DRIVER_PATH or something along those lines that can be passed in. </blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> My understanding was that the icd loader had a similar env var. </blockquote><div> </div><div>Depending on the loader you use, that might be the case, but the official ICD Loader code from Khronos (<a href="https://www.khronos.org/registry/cl/specs/opencl-icd-1.2.11.0.tgz">https://www.khronos.org/registry/cl/specs/opencl-icd-1.2.11.0.tgz</a>) has a hard-coded path of /etc/OpenCL/vendors/ </div><div>The spec requires any ICDs to be registered in that specific directory. On windows, things happen through the registry. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> How about this -- get rid of --enable-opencl-icd and change it to --with-opencl-icd-dir where you must supply a directory if you want to use it. That way if you want the system one, you'd say /etc/OpenCL/vendors, if you want your own custom dir, then put that in. <div class=""><div class="h5"> -ilia _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </div></div></blockquote></div> </div></div>