Здание из источника за пределами macports - легкий ветерок. Строительство с помощью macports берет навсегда и, кажется, замерзает os каждый так часто. Это типичное поведение? Хотя это похоже на хороший инструмент для упаковки os x, если мне приходится проходить эту боль каждый раз во время каждой установки, я думаю, что обойдусь без нее.Почему Macports берет FOREVER для создания простых пакетов?
Если вы работаете на Intel Core 2 Duo вы можете удвоить скорость сборок путем изменения параметра конфигурации MacPorts, расположенный здесь:
/opt/local/etc/macports/macports.conf
# Number of simultaneous make jobs (commands) to use when building ports
buildmakejobs 2
я пинал меня, когда я обнаружил, что это ПОСЛЕ перестроен GCC;)
Эта опция позволит вам использовать оба процессора для сборки пакетов.
спасибо за подсказку! моя тоже была прокомментирована! – ennuikiller
Может ли кто-нибудь подтвердить это? Комментарий к этому полю для меня говорит: «Это значение # может быть установлено равным 0, поэтому количество одновременных заданий будет установлено на # количество ядер ЦП, которые автоматически обнаружены, или количество GB # физического память плюс одна, в зависимости от того, что меньше ». ... поэтому, если обнаружение ЦП не сломано, или у вас есть <2 гигабайта, он должен уже делать правильные вещи. – Trenton
Проверьте это самостоятельно. Как я и сделал. Откройте «Монитор активности», нажмите «ЦП» и просмотрите разницу в активности каждого ядра, когда вы изменяете параметр во время создания. – galaxywatcher
"заморозить os"? Можете быть более конкретными? Какие пакеты вы пытались построить на какой версии OS X на какой машине?
По моему опыту, MacPorts, как правило, работает корректно практически на любой поддерживаемой конфигурации, в моем случае от 256 Мбайт Pismo G3 (2000 год), работающей на 10,4, хотя недавняя двухъядерная Intel iMac на 10,5. Однако вы должны быть терпеливы: это может занять много времени, особенно если есть много зависимых пакетов, что является одним из недостатков использования диспетчера пакетов, такого как MacPorts или Fink. Положительным моментом является то, что вы, как правило, обладаете гораздо более контролируемой и надежной средой, чем если бы вы сами устанавливали индивидуальные пакеты из исходного кода. И, если вы еще этого не сделали, убедитесь, что вы обновили последние версии MacPorts: 1.8.0 был только что выпущен и имеет некоторые важные улучшения, включая лучшую поддержку универсальных сборок.
+1 ... чтобы прослушивать с Недом, если то, что вы строите, имеет множество зависимостей пакетов (и эти пакеты имеют зависимости и т. Д.), Вы будете долго ждать, чтобы скомпилировать ваш материал. –
, замораживая os. Я имею в виду, что он перестает отвечать на несколько секунд. Я запускаю os x 10.6 на основной дуэт 2 macbook pro с 4gb mem. Достаточно того, чтобы обрабатывать даже самые интенсивные процессы cpu/mem. Я сравниваю macports с yum, который я использовал в Linux-системах довольно долгое время, и снова macports кажется намного менее подвижным .... – ennuikiller
Ваш компьютер периодически перестает реагировать, потому что много сборок и инсталляций имеют очень сильные шаблоны ввода-вывода и это узкое место на Disk IOs. Он не имеет ничего общего с процессором или памятью. Это не так плохо с yum, потому что yum устанавливает предварительно скомпилированные двоичные пакеты, а не строит их. –
Я не против ждать, пока Mac-порты будут строить из исходников на последних пакетах. Но почему бы не использовать всю эту вычислительную мощность и предложить пользователям возможность автоматически загружать сборку в MacPorts или еще лучше хешировать и предлагать одноранговое подключение другим пользователям MacPorts, которые могут выбрать вариант «турбо».
Наверное, потому что в эти дни люди (включая меня) слишком параноидальные, чтобы доверять бинарнику от незнакомца. Самое забавное, что большинство из нас никогда не потрудились заглянуть в исходный код, который мы каждый день строим .... –
Я нашел этот вопрос, когда задавался вопросом, почему он строит, а не устанавливает двоичный код, поскольку этот «ответ» задается вопросом ... Что касается доверие, ну, если мы доверяем исходному дереву macports, то я не вижу причин не доверять, скажем, макросозданию сборки вещей.Для этого требуется, чтобы у людей с макроблоками были ресурсы (оборудование, время и т. Д.) Для создания вещей (для разных платформ), но ... возможно, есть какой-то промежуточный путь? Я знаю, что предпочел бы бинарные установки, если бы была какая-то сравнительная степень доверия. Это, безусловно, не менее безопасно (по сути, в любом случае), чем источник, на который он не смотрит. – lindes
Не на основе p2p, но это происходит с 2.0, но не все пакеты доступны из-за доступности лицензии и ресурсов (сборщик должен обработать файл до того, как архив будет доступен). Архивы подписаны, ср. http://packages.macports.org – anddam
MacPorts используется только для сборки из источника, и это может привести к разнице в несколько порядков magnitudo по сравнению с системой пакетов, которая извлекает двоичные файлы. Рассмотрим пример случайного пакета, который занимает несколько часов, и сравнивает его со временем загрузки его в виде архива размером в несколько десятков МБ.
MacPorts использует инструменты Apple для сборки, и это лишь добавляет незначительные накладные расходы к тому же времени сборки, которое вы выберете за пределами MacPorts, чем больше пакет, тем меньше разница. Если вы испытываете огромную разницу при создании программы вне MP, вы должны подать билет на issue tracker с подробной информацией.
Это говорит, что я вижу, что вопрос довольно старый, поскольку 2.0 есть поддержка двоичных архивов -cf. Changelog - есть поддерживаемый macosforge репозиторий со сборщиками, которые создают подписанные архивы, а по умолчанию - извлечение этих двоичных архивов, а не создание из источника (что вы можете принудительно использовать -s-флаг). Современный пользовательский интерфейс больше похож на двоичных менеджеров, таких как apt-get, с возможностью легко изменять параметры конфигурации и сборки.
Этот вопрос не рассматривается ниже. Контрастность производительности macports для любого другого менеджера пакетов, такого как apt-get, должна быть порядка 100 раз медленнее. – user363349
Если у вас нет фактического теста, вы не должны использовать произвольные количества «100 раз». – anddam
@ user363349: Нечестно сравнивать macports с apt-get; Репозитории экосистемы Linux обычно имеют дело с предварительно скомпилированными двоичными файлами. Макросы собираются каждый раз из источника. Разница в скорости может быть объяснена подходом. –