我编写在共享工作区中使用的工具。由于这个领域有多个操作系统在工作，我们通常使用 Python 并标准化跨机器安装的版本。但是，如果我想用 C 编写一些东西，我想知道是否可以将应用程序包装在 Python 脚本中，从而检测操作系统并启动正确版本的 C 应用程序。每个平台都有可用的 GCC 并使用相同的 shell。
一个想法是将 C 编译到用户本地 ~/bin，并与 C 代码进行时间戳比较，因此不会在每次运行时编译它，而仅在更新代码时编译。另一个是为每个平台编译它，并让包装脚本选择正确的可执行文件。
是否有一个可接受/稳定的过程？有什么问题吗？是否有替代方案（假设绝对需要使用本机 C 代码）？
澄清：涉及多个不共享 ABI 的操作系统。例如。OS X、各种 Linux、BSD 等。我需要能够更新共享文件夹中的代码，并让新代码或多或少即时工作。分发二进制或源代码包并不理想。
Launching a Python interpreter instance just to select the right binary to run would be much heavier than you need. I'd distribute a shell .rc file which provides aliases.
In /shared/bin, you put the various binaries: /shared/bin/toolname-mac, /shared/bin/toolname-debian-x86, /shared/bin/toolname-netbsd-dreamcast, etc. Then, in the common shared shell .rc file, you put the logic to set the aliases according to platform, so that on OSX, it gets alias toolname=/shared/bin/toolname-mac, and so forth.
This won't work as well if you're adding new tools all the time, because the users will need to reload the aliases.
I wouldn't recommend distributing tools this way, though. Testing and qualifying new builds of the tools should be taking up enough time and effort that the extra time required to distribute the tools to the users is trivial. You seem to be optimizing to reduce the distribution time. Replacing tools that quickly in a live environment is all too likely to result in lengthy and confusing downtime if anything goes wrong in writing and building the tools--especially when subtle cross-platform issues creep in.
此外，您可以使用 autoconf 并仅以源代码形式分发您的应用程序。:)
你知道，你应该看看静态链接。
这些天来，我们都有巨大的硬盘驱动器，而额外的几兆字节（用于携带 libc 等等）真的不再那么重要了。
您还可以尝试在 chroot() 监狱中运行您的应用程序并分发它们。
根据您的混合操作系统操作系统，您最好为每类系统创建包。
或者，如果它们都共享相同的 ABI 和硬件架构，您也可以编译静态二进制文件。