Почему Macports использует FOREVER для создания простых пакетов? - PullRequest
42 голосов
/ 30 августа 2009

Сборка из источника за пределами macports - это бриз. Сборка с помощью macports занимает вечно и, кажется, время от времени останавливает ОС. Это типичное поведение? Хотя это кажется хорошим инструментом для упаковки OS X, если мне придется проходить через эту боль каждый раз во время каждой установки, я думаю, что я обойдусь без нее.

Ответы [ 4 ]

35 голосов
/ 25 ноября 2009

Если вы работаете на Intel Core 2 Duo, вы можете удвоить скорость своих сборок, изменив опцию конфигурации Macports, расположенную здесь:

/ опция / местные / и т.д. / MacPorts / macports.conf

# Number of simultaneous make jobs (commands) to use when building ports
buildmakejobs       2

Я пинал себя, когда обнаружил это ПОСЛЕ того, как я восстановил gcc;)

Эта опция позволит вам использовать оба процессора для сборки пакетов.

8 голосов
/ 30 августа 2009

"заморозить ОС"? Можете быть более конкретными? Какие пакеты вы пытались собрать на какой версии OS X на какой машине?

По моему опыту, сборки MacPorts в целом работают корректно практически на любой поддерживаемой конфигурации, в моем случае - от 256 МБ Pismo G3 (2000 год) с 10,4 до недавнего двухъядерного Intel iMac на 10,5. Вы должны быть терпеливы, хотя: это может занять много времени, особенно если есть много зависимых пакетов, что является одним из недостатков использования менеджера пакетов, такого как MacPorts или Fink. Положительным моментом является то, что у вас, как правило, гораздо более контролируемая и, как мы надеемся, проверенная среда, чем если бы вы устанавливали отдельные пакеты из исходного кода самостоятельно. И, если вы этого еще не сделали, убедитесь, что вы обновили MacPorts до последней версии: 1.8.0 был только что выпущен и имеет некоторые важные улучшения, включая лучшую поддержку универсальных сборок.

5 голосов
/ 03 сентября 2012

MacPorts используется только для сборки из исходного кода, и это может привести к разнице в несколько порядков по сравнению с системой пакетов, которая извлекает двоичные файлы. В качестве примера рассмотрим случай создания какого-то большого пакета, для сборки которого требуется несколько часов, и сравните его со временем загрузки его в виде архива размером в несколько десятков МБ.

MacPorts использует инструменты Apple для сборки, и это только добавляет незначительные накладные расходы к тому же времени сборки, которое вы получаете за пределами MacPorts, чем больше пакет, тем меньше разница. Если вы испытываете огромную разницу при создании программы за пределами MP, вы должны подать заявку на систему отслеживания проблем с подробной информацией.

Тем не менее, я вижу, что вопрос довольно старый, так как в 2.0 есть поддержка бинарных архивов -cf. Changelog - существует поддерживаемый macosforge репозиторий со сборочными ботами, которые создают подписанные архивы, и по умолчанию выбирают эти двоичные архивы, а не строят из источника (который можно принудительно использовать с помощью флага -s). В настоящее время пользовательский интерфейс больше похож на двоичные менеджеры, такие как apt-get, с возможностью довольно легко изменять параметры конфигурации и сборки.

4 голосов
/ 19 июня 2010

Я не против подождать, пока порты Mac соберутся из исходного кода на последних версиях. Но почему бы не использовать все эти вычислительные мощности и предложить пользователям возможность автоматически загружать сборку обратно в MacPorts или, что еще лучше, хэшировать и предлагать одноранговый доступ другим пользователям MacPorts, которые могут выбрать вариант «турбо».

...