Определение среды выполнения

Question

Мне нужно определить среду выполнения для моей разработки.Первая идея, конечно, заключается в том, чтобы не изобретать велосипед заново.Я скачал macports, воспользовался easy_install, попробовал fink.У меня всегда были проблемы.Например, прямо сейчас я не могу скомпилировать scipy, потому что установщик MacPorts хочет загрузить и установить gcc43, но это не компилируется в Snow Leopard.Для этой проблемы открыта ошибка, но я в основном привязан к ним, чтобы моя среда выполнения была полезной.

Метод, которому я научился некоторое время назад, заключался в написании makefile для загрузки и сборки среды выполнения / библиотек с четко указанными версиями библиотек и утилит.Это предшествовало подходу MacPorts / fink / apt, но у вас гораздо больше контроля над ним, хотя вам приходится все делать вручную.Конечно, это может стать кошмаром само по себе, если время выполнения растет, но если вы обнаружите проблему, вы можете использовать patch и устраните проблему в загруженном пакете, а затем соберите его.

У меня есть несколько вопросов:

• Каков ваш метод подготовки четко определенной среды выполнения / коллекции библиотек для вашей разработки?
• Позволяет ли MacPorts / fink / что угодно мне такую же гибкость при повторном взломе, если что-то пойдет не так?
• Учитывая мое решение makefile, когда мое программное обеспечение, наконец, будет готово для загрузки, каковы ваши предложения по устранению потенциальных проблем между моей средой разработки и реальной платформой на компьютерах моих пользователей?

Редактировать:Чего я, в частности, не понимаю, так это того, что другие проекты не дают мне подсказок.Например, я только что скачал scipy, сложную библиотеку с большим количеством зависимостей.Разработчики должны иметь все настройки deps, прежде чем работать над этим.Несмотря на это, в svn нет ничего, что создавало бы эту среду.

Редактировать:Добавил награду к вопросу.Я думаю, что это важный вопрос, и он заслуживает того, чтобы получить больше ответов.Я лучше всего рассмотрю эти ответы на примерах из реального мира, уделяя особое внимание любым возникшим проблемам и их решению.

Дополнительные вопросы, вдохновляющие на получение награды:

• Проводите ли вы тестирование в своей среде (для проверки правильности установки, напримерна интеграционной машине)?
• Как вы включаете свое окружение во время доставки?Если это C, вы статически связываете его или отправляете динамическую библиотеку, изменяя LD_LIBRARY_PATH перед запуском исполняемого файла?Как насчет той же проблемы для python, perl и других?
• Придерживаетесь ли вы среды выполнения или обновляете ее по прошествии времени?Загружаете ли вы "магистральные" пакеты ваших библиотек зависимостей или фиксированную версию?
• Как вы справляетесь с такими ситуациями, как:библиотеке foo нужен python 2.5, но вам нужно разрабатывать на python 2.4, потому что library bar не работает с python 2.5?

Answer 1

Мы используем скрипт CMake, который генерирует Make-файлы, которые загружают (в основном через SVN) / настраивают / создают все наши зависимости.Почему CMake?Мультиплатформенный.Это работает довольно хорошо, и мы поддерживаем вызов scons /autopain /cmake.Поскольку мы работаем на нескольких платформах (Windows, MacOSX, несколько вариантов Linux), мы также поддерживаем различные флаги компиляции и т.д. В зависимости от операционной системы.Обычно библиотека имеет конфигурацию по умолчанию, и если мы сталкиваемся с системой, которая нуждается в специальной конфигурации, конфигурация заменяется специализированной конфигурацией.Это работает довольно хорошо.На самом деле мы не нашли ни одного готового решения, которое соответствовало бы нашей цели.

Тем не менее, запустить его очень просто - нужно повернуть множество ручек, когда вам нужно поддерживать несколько операционных систем.Я не думаю, что это станет кошмаром для обслуживания, поскольку зависимости достаточно исправлены (библиотеки регулярно обновляются, но мы редко вводим новые).

Answer 2

virtualenv это хорошо, но оно не может творить магию - напримересли вы хотите использовать библиотеку, которая просто ОБЯЗАНА иметь Python 2.4 и еще один вариант, который абсолютно НУЖДАЕТСЯ в 2.5 вместо этого, - вам не повезло.Virtualenv (или любой другой инструмент) также не может помочь, когда выходит совершенно новая версия ОС, а половина инструментов и c просто еще не поддерживают ее, как вы упомянули для Snow Leopard:некоторые проблемы просто невозможно решить (две библиотеки с абсолютно противоречивыми потребностями в рамках одной сборки), другие просто требуют терпения (пока все необходимые инструменты не будут перенесены на новую версию ОС, вам просто нужно придерживаться предыдущей версии ОС).