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

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

是否有一个公认的/稳定的过程？有渔获吗？是否有其他选择(假设绝对需要使用本机C代码)？

澄清：涉及多个不共享ABI的OS。例如。 OS X，各种Linux，BSD等。我需要能够更新共享文件夹中的代码，并使新代码或者多或者少地即时起作用。分发二进制或者源程序包不理想。

解决方案

回答

我们知道，我们应该看一下静态链接。

如今，我们所有人都拥有巨大的硬盘驱动器，而额外的几兆字节(用于携带libc之类的东西)实际上已经不再是什么大问题了。

我们也可以尝试在chroot()监狱中运行应用程序并将其分发。

回答

根据混合操作系统，最好为每类系统创建软件包。

或者，如果它们都共享相同的ABI和硬件体系结构，则还可以编译静态二进制文件。

回答

另外，我们可以使用autoconf并仅以源代码形式分发应用程序。 :)

回答

仅为了选择正确的二进制文件而启动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，依此类推。

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

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