在共享的多平台POSIX环境中使用C
我在一个共享的工作空间里写工具。因为这个空间里有很多不同的操作系统，所以我们通常使用Python，并且在所有机器上统一安装同一个版本。不过，如果我想用C语言写一些东西，我在想能不能把这个应用程序放在一个Python脚本里，这个脚本可以检测操作系统，然后启动正确版本的C应用程序。每个平台都有GCC这个编译器，并且使用的是相同的命令行界面。
我有一个想法，就是把C代码编译到用户本地的~/bin文件夹里，并通过时间戳来比较C代码，这样就不会每次运行都编译，而是只有在代码更新时才编译。另一个想法是为每个平台单独编译，然后让包装脚本选择合适的可执行文件。
这样做有没有什么被接受的、稳定的流程？有没有什么需要注意的地方？如果必须使用原生的C代码，还有没有其他的选择？
补充说明：涉及到多个操作系统，它们之间不共享ABI（应用程序二进制接口）。比如说OS X、各种Linux和BSD等。我需要能够在共享文件夹中直接更新代码，并且让新代码几乎立刻生效。分发二进制文件或源代码包并不是最理想的选择。
4 个回答
你知道吗，其实你应该考虑一下静态链接。
现在我们都有很大的硬盘，几兆字节的额外空间（比如说携带一些库文件什么的）其实也没那么重要了。
你还可以试试在 chroot() 沙箱里运行你的应用程序，然后把它们分发出去。
另外，你可以使用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，其他平台也是类似的。
不过，如果你总是添加新的工具，这样做就不太方便了，因为用户需要重新加载别名才能使用新工具。
不过，我不太建议你用这种方式来分发工具。测试和验证新版本的工具本身就需要花费不少时间和精力，所以分发工具给用户所需的额外时间其实是微不足道的。你似乎在优化分发时间，但在实际环境中快速替换工具，如果在编写和构建工具时出现问题，可能会导致长时间的混乱停机，尤其是当一些微妙的跨平台问题出现时。