[Mesa-dev] [PATCH] mesa: Add mesa SHA-1 functions

[Emil Velikov]

On 14/12/14 17:19, Matt Turner wrote:
> On Sun, Dec 14, 2014 at 7:06 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 11/12/14 21:51, Carl Worth wrote:
>>> From: Kristian Høgsberg <krh at bitplanet.net>
>>>
>>> The upcoming shader cache uses the SHA-1 algorithm for cryptographic
>>> naming. These new mesa_sha1 functions are implemented with the nettle
>>> library.
>>> ---
>>>
>>> This patch is another in support of my upcoming shader-cache work. Thanks to
>>> Kritian for coding this piece.
>>>
>>> As currently written, this patch introduces a new dependency of Mesa on the
>>> Nettle library to implement SHA-1. I'm open to recommendations if people would prefer some other option.
>>>
>>> For example, the xserver can be configured to get a SHA-1 implementation from
>>> libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or
>>> openssl.
>>>
>>> I don't know if it's important to offer as many options as that, which is why
>>> I'm asking for opinions here.
>>>
>> Hi Carl,
>>
>> Can we try to avoid adding new dependencies to mesa unless absolutely
>> needed. Neither of the proprietary drivers does so presently, so it will
>> be nice to keep the trend.
>>
>> While currently the steam runtime does not include libnettle I can
>> envision one day that they will/might. Even with steam aside I think
>> that this might cause issues with gnome & others' sandboxing.
>>
>> Long story short - can we import a sha1 implementation from another
>> project ? It will save us the "libstdc++ style steam runtime" issues,
>> plus it will ease the question of what to do under Windows :)
> 
> It's working okay for the xserver, isn't it?
> 
The xserver is linking against libudev and we all know how nicely that
one went.

Here are the libs that we're missing wrt xserver:
  NEEDED               libdbus-1.so.3
  NEEDED               libudev.so.1
  NEEDED               libgcrypt.so.20
  NEEDED               libpciaccess.so.0
  NEEDED               libpixman-1.so.0
  NEEDED               libXfont.so.1
  NEEDED               libXau.so.6
  NEEDED               libsystemd.so.0
  NEEDED               libxshmfence.so.1
  NEEDED               libXdmcp.so.6


Imho going for a "having as little external dependencies as possible"
sounds better than "how many can we stuff in and get away with".
Admittedly those are extraditions yet they nicely indicate the opposing
directions.

Would static linking library X be a better solution than syncing its
source into mesa every Y months ?

Cheers,
Emil

P.S. If my arguments sound flaky at least consider the ones put by OG.