On Oct 20, 2016 8:11 AM, "Emil Velikov" <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: > > On 19 October 2016 at 20:31, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > On Wed, Oct 19, 2016 at 12:16 PM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> > > wrote: > >> > >> On 19 October 2016 at 19:50, Kai Wasserbäch <<a href="mailto:kai@dev.carbon-project.org">kai@dev.carbon-project.org</a>> > >> wrote: > >> > Hey Emil, > >> > just curious why you did the revert > >> > > >> > (<<a href="https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04">https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04</a>>). > >> > Wouldn't distros just set --disable-vulkan-icd-full-driver-path (I know > >> > I'm > >> > doing that for Multi-Arch compatibility for my local builds)? > >> > > >> Yes they can, yet they shouldn't need to bother to begin with, since > >> the code itself is not aimed at deployment ;-) > > > > > > What code isn't aimed at deployment? > > > > Don't just go reverting commits in the release branch on your own authority > > with no discussion. If that flag is causing problems for distros and > > packagers, let's hear from them and they can tell us what they need. > > > I believe I mentioned it before - due to the high traffic on mesa-dev@ > little-to-no distro maintainers get to read upon decisions and/or cast > their opinion. In most cases they'll just workout something locally > and not bother (-ETIME or other) prodding upstream. > > I believe I explained it in length why the original and follow up are > bad idea, suggested two alternative solutions and a Nack on the patch. > Only to get all that fall though the cracks :-\ > > > Also, it's not in there for developers. It's in there for people who want > > to do a local build and have "make install" work somewhat correctly. > Doing `make install' to a non-default prefix falls in the > development/testing category. > > In either case using LD_LIBRARY_PATH is a must _regardless_ of the > software that one's building/testing. That is unless you're using > chroot :-) ./configure --prefix=$HOME/.local make make install Works today without LD_LIBRARY_PATH > > They're free to do that local build from a release branch or a tarball and > > it should still work. > > > > Also, you're making piles of pain for packagers who > > now have a configure flag that works in 12.0 git and 13.0 git but in 13.0 > > release it is gone. > Please don't get me wrong, but I think you're over-dramatizing this a > little. Can you be specific where this has caused/will cause pain ? > > I regularly check what distros do and try to steer them as things get > rocky. The revert helps exactly this - it removes the "pain" that it > would cause to distros since there's a) new option and b) the default > value of it is _against_ their preference. > > Thanks > Emil