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

[Kai Wasserbäch]

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.

Cheers,
Kai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161020/cad0f7fb/attachment.sig>