定义运行时环境
我需要为我的开发定义一个运行时环境。第一个想法当然不是重新发明轮子。我下载了 macports，使用了 easy_install，尝试了 fink。我总是遇到问题。例如，现在我无法编译 scipy，因为 MacPorts 安装程序想要下载并安装 gcc43，但这无法在 Snow Leopard 上编译。这个问题存在一个错误，但我基本上与它们联系在一起，以便我的运行时可用。
我前段时间学到的一项技术是编写一个 makefile 来下载和构建带有明确指定版本的库和实用程序的运行时/库。这早于 MacPorts/fink/apt 方法，但您对它有更多的控制权，尽管您必须手动完成所有操作。当然，如果运行时增长，这本身可能会成为一场噩梦，但如果您发现问题，您可以使用 patch 并修复下载的包上的问题，然后构建它。
我有多个问题：
- 您为开发准备明确定义的运行时/库集合的技术是什么？
- 如果出现问题，MacPorts/fink/whatever 是否允许我同样灵活地进行重新黑客攻击？
- 考虑到我的 makefile 解决方案，当我的软件最终可供下载时，您对解决我的开发环境和用户计算机上的实际平台之间的潜在问题有何建议？
编辑：我特别不明白的是其他项目没有给我提示。例如，我刚刚下载了 scipy，一个具有大量依赖项的复杂库。开发人员在开始工作之前必须先设置好所有部门。尽管如此，svn 中没有任何东西可以创建这个环境。
编辑：为问题添加了赏金。我认为这是一个重要的问题，值得得到更多的答案。我将用现实世界的例子来最好地考虑这些答案，特别关注任何出现的问题及其解决方案。
激发赏金的其他问题：
- 您是否对您的环境进行测试（以检查安装是否正确，例如在集成机器上）？
- 您如何在运输时考虑您的环境？如果是 C，您是否静态链接它，或者发送动态库，在运行可执行文件之前修改 LD_LIBRARY_PATH？对于 python、perl 和其他语言来说，同样的问题又如何呢？
- 您是坚持运行时，还是随着时间的推移而更新它？您下载的是依赖库的“主干”包还是固定版本？
- 您如何处理以下情况：库 foo 需要 python 2.5，但您需要在 python 2.4 中开发，因为库 bar 不适用于 python 2.5 ？
I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
- What is your technique to prepare a well-defined runtime/library collection for your development?
- Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
- Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
- Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
- How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
- Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
- How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们使用 CMake 脚本生成 Makefile，下载（主要通过 SVN）/配置/构建所有依赖项。为什么选择 CMake？多平台。这工作得很好，我们支持调用 scons/autopain/cmake。当我们在多个平台（Windows、MacOSX、一系列 Linux 变体）上构建时，我们还根据操作系统支持不同的编译标志等。通常，库有一个默认配置，如果我们遇到需要特殊配置的系统，则该配置会被替换为专门的配置。这非常有效。我们并没有真正找到任何适合我们目的的现成解决方案。
话虽如此，它是一个 PITA 来启动并运行它 - 当您需要支持多个操作系统时，有很多旋钮需要转动。我不认为这会成为维护的噩梦，因为依赖关系非常固定（库会定期升级，但我们很少引入新的库）。
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv 很好，但它不能发挥魔力 - 例如，如果您如果你想使用一个必须有 Python 2.4 的库，而另一个绝对需要 2.5 的库，那么你就不走运了。当有一个全新的操作系统版本并且一半的工具和c还不支持它时，virtualenv（或任何其他工具）也无法提供帮助，正如您在雪豹中提到的：有些问题是不可能解决的（两个同一版本中需求完全冲突的库），其他人只需要耐心（直到您需要的所有工具都移植到新操作系统的版本中，您只需要坚持使用以前的操作系统版本）。
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).