我编写共享工作区中使用的工具。由于有多个操作系统在这个空间中工作，我们通常使用Python并标准化跨机器安装的版本。但是，如果我想在C中编写一些东西，我想知道是否可以将应用程序包装在Python脚本中，检测操作系统并启动正确版本的C应用程序。每个平台都有可用的GCC并使用相同的shell。
一个想法是将C编译到用户本地〜/ bin，与C代码进行时间戳比较，这样每次运行都不会编译，但只有在代码更新时才编译。另一个是为每个平台编译它，并让包装脚本选择正确的可执行文件。
是否有接受/稳定的流程？有捕获吗？是否有替代方案（假设绝对需要使用本机C代码）？
澄清：涉及不共享ABI的多个操作系统。例如。 OS X，各种Linux，BSD等。我需要能够在共享文件夹中更新代码，并使新代码或多或少地即时运行。分发二进制或源包不太理想。
答案 0 :(得分：2)
启动Python解释器实例只是为了选择正确运行的二进制文件将比你需要的要重得多。我将发布一个提供别名的shell .rc文件。
在/ shared / bin中，你放了各种二进制文件：/ shared / bin / toolname-mac，/ shared / bin / toolname-debian-x86，/ shared / bin / toolname-netbsd-dreamcast等。然后，在公共共享shell .rc文件中，您根据平台设置了别名的逻辑，因此在OSX上，它获取别名toolname = / shared / bin / toolname-mac，等等。
如果您一直在添加新工具，这将无法正常工作，因为用户需要重新加载别名。
但是，我不建议以这种方式分发工具。测试和验证工具的新版本应该花费足够的时间和精力，以便将工具分发给用户所需的额外时间是微不足道的。您似乎正在优化以减少分发时间。如果在编写和构建工具时出现任何问题，那么在实时环境中快速更换工具很可能会导致冗长和混乱的停机时间 - 特别是当微妙的跨平台问题蔓延时。答案 1 :(得分：1)
此外，您可以使用autoconf并仅以源代码形式分发您的应用程序。 ：）
答案 2 :(得分：0)
你知道，你应该看静态链接。
现在，我们都拥有巨大的硬盘驱动器，而且还有一些额外的兆字节（用于携带libc而不是什么）并不是那么重要。
您还可以尝试在chroot（）jails中运行应用程序并分发它们。
答案 3 :(得分：0)
根据您的混合OS操作系统，您可能最好为每类系统创建包。
或者，如果它们共享相同的ABI和硬件体系结构，您也可以编译静态二进制文件。