python - 在共享的多平台 POSIX 环境中使用 C

Question

我编写在共享工作区中使用的工具。由于在这个空间中有多个操作系统在工作，我们通常使用 Python 并标准化跨机器安装的版本。但是，如果我想用 C 编写一些东西，我想知道是否可以将应用程序包装在 Python 脚本中，该脚本可以检测操作系统并启动正确版本的 C 应用程序。每个平台都有可用的 GCC 并使用相同的 shell。

一个想法是将 C 编译到用户本地 ~/bin，并与 C 代码进行时间戳比较，这样它就不会在每次运行时编译，而是仅在代码更新时编译。另一种方法是只为每个平台编译它，并让包装器脚本选择适当的可执行文件。

是否有一个可接受的/稳定的流程？有什么问题吗？是否有替代方案(假设绝对需要使用 native C 代码)？

澄清:涉及不共享 ABI 的多个操作系统。例如。 OS X、各种 Linux、BSD 等。我需要能够更新共享文件夹中的代码，并让新代码或多或少立即工作。分发二进制或源代码包并不理想。

Answer 1

启动 Python 解释器实例只是为了选择要运行的正确二进制文件，这比您需要的要繁重得多。我会分发一个提供别名的 shell .rc 文件。

在/shared/bin 中，您放置各种二进制文件:/shared/bin/toolname-mac、/shared/bin/toolname-debian-x86、/shared/bin/toolname-netbsd-dreamcast 等。然后，在公共(public)共享 shell .rc 文件中，您放置了根据平台设置别名的逻辑，因此在 OSX 上，它获得别名 toolname=/shared/bin/toolname-mac，等等。

如果您一直在添加新工具，这将无法正常工作，因为用户将需要重新加载别名。

不过，我不建议以这种方式分发工具。测试和验证工具的新版本应该占用足够的时间和精力，因此将工具分发给用户所需的额外时间是微不足道的。您似乎正在优化以减少分发时间。如果在编写和构建工具时出现任何问题，在实时环境中快速更换工具很可能会导致漫长而困惑的停机时间——尤其是当微妙的跨平台问题悄然出现时。