我目前正在使用 Yocto 4.0.14 Kirkstone - Bitbake 版本 2.0.0
在使用 Yocto 方面我还是个初学者。 SState 缓存数据位于内部 (HTTPS) 缓存服务器上。 我想从各种设备使用这个缓存。 目标是最大限度地提高构建安全性并尽可能节省时间。 我正在寻找的是如何做到这一点的“最佳实践”。
到目前为止我认为正确设置SState_Mirror就足够了。 但自从我收到这个警告：
警告：您正在使用本地哈希等效服务器，但已配置 sstate 镜像。这可能意味着镜像中不会有任何状态匹配。您可能希望禁用哈希等价使用 (BB_HASHSERVE)，或在 sstate 镜像旁边使用哈希等价服务器。
我认为我不能忽略这个警告。
现在我已经寻找了一段时间我到底需要设置什么。我收到了各种错误消息并尝试了很多。 根据我当前的设置，没有错误消息，也没有警告。 我目前有
SSTATE_MIRRORS ?= "file://.* https://xxx.c.de/PATH;downloadfilename=PATH"
BB_HASHSERVE = ""
BB_HASHSERVE_UPSTREAM = ""
BB_SIGNATURE_HANDLER = ""
设置。 而且看起来它无法正常工作。 更改配方后，我们没有意识到部分缓存无法再使用，必须重新创建。 Bitbake 构建中止。删除我服务器上 SState 镜像缓存中的特定文件后，它才再次起作用。
谁能回答我需要哪些最低设置/配置才能完成这项工作的问题？
我认为只要使用镜像的机器找到镜像的sstate缓存中的对象，就可以放心地忽略该警告。
据我了解，sstate 缓存机制的工作原理如下：
BitBake 根据以下几个因素为每个配方的每个任务生成一个哈希值：环境变量、当前任务所依赖的任务的哈希值等等。 如果您重建配方并且没有任何更改，它将生成相同的哈希值并在本地缓存中查找已完成的任务。 如果某些变化会影响哈希值但不会改变配方的结果，则本地等效哈希服务器就会发挥作用。它在数据库中记录新旧哈希值之间的等价性，从而避免了重建配方的需要。 如果在本地缓存中没有找到该哈希值，BitBake 将检查镜像缓存。在这种情况下，本地等价哈希服务器可能会认为该哈希无效，而如果您配置了镜像等价哈希服务器，则可以避免重建。 如果除了本地服务器之外，您还想使用镜像中的等价哈希服务器（并避免警告），您可以执行以下操作：
BB_HASHSERVE_UPSTREAM =“xxx.c.de:6789”
然后，在 xxx.c.de 机器上，使用此命令启动哈希服务器
nohup bitbake-hashserv -b xxx.c.de:6789 -d
这是一个有用的链接，其中所有概念的解释都比我更好：
https://www.thegoodpenguin.co.uk/blog/improving-yocto-build-time/