[Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc1

[Emil Velikov]

On 20 October 2016 at 20:46, Kai Wasserbäch <kai at dev.carbon-project.org> wrote:
> Hey Emil, hey Jason,
> Emil Velikov wrote on 20.10.2016 17:28:
>> On 20 October 2016 at 16:20, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Oct 20, 2016 8:11 AM, "Emil Velikov" <emil.l.velikov at gmail.com> wrote:
>>>>
>>>> On 19 October 2016 at 20:31, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>>> On Wed, Oct 19, 2016 at 12:16 PM, Emil Velikov
>>>>> <emil.l.velikov at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On 19 October 2016 at 19:50, Kai Wasserbäch
>>>>>> <kai at dev.carbon-project.org>
>>>>>> wrote:
>>>>>>> Hey Emil,
>>>>>>> just curious why you did the revert
>>>>>>>
>>>>>>>
>>>>>>> (<https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04>).
>>>>>>> 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
>>>
>> "In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
>> software that one's building/testing".
>>
>> I realise that the Vulkan spec does not mention that, but this is a
>> common practise that everyone should be using.
>>
>> Mildly related: I thought you/others are using VK_ICD_FILENAMES +
>> dev_icd.json. Or is that one somehow wrong/deprecated ?
>
> maybe the solution to this discussion can be to switch the default around then?
> By default you get the relative (just library name), and if you set something
> like "--with-vulkan-icd-loader-path=..." you get a full path?
> That way distributions don't have to do anything and developers can set it
> easily enough.
>
Better yet, Jason got a series which generates distinct, per-cpu json
file with each one containing the full path + name of the driver.
This way as the loader iterates over the json files, it will (attempt
to) dlopen all of them and manage only the ones that work.

Thanks
Emil