你好 - 我帮助为conda-forge打包很多包，这是一个非常庞大的生态系统，尤其是在数据科学和机器学习/人工智能方面。它最初主要关注Python,但也包括许多其他语言。
一个强大的点(特别是与pip相比)是，我们能够合理地重新分发非Python制品。我们可以跟踪一个包的相关ABI,并在必要时重建其后代包。这使我们能够(几乎)仅分发共享库，从而降低包的足迹，并带来其他一些好处。
我们已经通过所谓的feedstock分发了sentencepiece大约3年了，包可以通过以下方式安装：

conda install -c conda-forge sentencepiece  # or mamba instead of conda

我们有针对linux-{64, aarch64, ppc64le},osx-{64, arm64},win-64以及CPython 3.8-3.11和PyPy 3.8 & 3.9的构建。
在想要packagetorchtext(这取决于sentencepiece - 但实际上只有C++部分)的情况下，我想将一个单独的“输出”/“包”称为libsentencepiece,torchtext可以构建它，而无需为每个python版本不必要地重新构建它(实际上在每种情况下都是一样的)。
此外，至关重要的是，我们绝对需要依赖我们自己的abseil和protobuf构建，这成为一个相当大的障碍。我终于设法在去年完成了这个split(那里有对我非常冗长的先前尝试的引用；最终我放弃了尝试在windows上构建共享库，因为它变得太疯狂了)。
然而，当时我没有动力在这里提出问题，并讨论如何 - 如果可能的话 - 将这些更改上游化。这更加重要，因为我提出的一些补丁绝对不是这里准备好的。我对thirdparty/absl中的代码既不是第三方的也不是abseil本身感到非常沮丧，所以我最终完全替换了它。当然，这并不意味着我建议在这里逐字照搬。
然而，abseil的情况可能是最大的障碍之一。有一个变量叫做SPM_USE_EXTERNAL_ABSL,但它实际上并没有像它说的那样做，因为所有的包含路径仍然指向third_party/absl,而不是abseil本身。这个问题也被其他人遇到了：#869。
自从我提出了我的初始补丁以来，sentencepiece不再强制使用MSVC运行时的静态链接(太好了！)。对我们来说的其他必要的更改列表：

• 允许关闭构建静态库(我们真的不想在任何地方都有它们)
• 使用外部protobuf和abseil(包括可能的共享构建，这需要设置PROTOBUF_USE_DLLS等)
• 强制使用C++17(我们需要这个，因为abseil的ABI取决于标准版本，我们需要在所有地方保持一致)
• 尊重CMAKE_INSTALL_PREFIX
• 为库添加cmake和pkg-config元数据
• 允许在已安装的libsentencepiece上构建python绑定(在我们的情况下，这将始终与底层版本1:1匹配，尽管sentencepiece的ABI保证或缺乏保证是可以知道的)

我已经根据0.1.99重新调整了我补丁(branch),目前正在重新构建我们的再分发recipe,针对protobuf 3.21和4.23(之后还会运行测试套件以捕获回归)。如果我们能找到一种方法让这些改进流回上游就好了。🙃
(我完全理解有些更改是我们特定需求的一部分，如果我们保留一些补丁也是可以的；但是任何减少都会有帮助，我相信其中一些更改也会对其他人有好处)
我很乐意为个别更改准备专用的PRs,但想先讨论一下这里维护者感兴趣的哪些部分，以及我们如何使它们容易合并到这里(例如基于符号或CMake响应环境变量的切换)。

脚注

1.到那时我已经在修补由protobuf生成的输出以解决一些愚蠢的constexpr错误↩
2.正如用实际的abseil替换它会导致构建错误一样，因为在我的理解中，它包含了sentencepiece特定的粘合代码，但位于absl命名空间中。↩
3.至少随着protobuf 23的到来应该会变得更容易，因为autotools已经消失了，而且我们对于CMake / pkgconfig有更好的元数据。↩