2009-08-29 12 views
42

Budowanie ze źródła poza portem Macports to pestka. Budowanie za pomocą Macports trwa wiecznie i wydaje się, że zamarza ono co jakiś czas. Czy to typowe zachowanie? Chociaż wydaje się, że jest to ładne narzędzie do pakowania os x, jeśli będę musiał przejść przez ten ból za każdym razem podczas każdej instalacji, myślę, że obejdę się bez niego.Dlaczego Macports wymaga FOREVER do tworzenia prostych pakietów?

+3

Nie uważam na to pytanie odpowiedział poniżej. Porównaj wydajność macportów z jakimkolwiek innym menedżerem pakietów, takim jak apt-get, który musi być rzędu 100 razy wolniejszy. – user363349

+2

Jeśli nie masz rzeczywistego testu, nie powinieneś używać arbitralnych ilości "100 razy". – anddam

+0

@ user363349: Nie należy godzić się z porównywaniem macportów do apt-get; W repozytoriach systemów Linux zazwyczaj występują wstępnie skompilowane pliki binarne. Macport kompiluje się za każdym razem ze źródła. Różnicę w prędkości można wytłumaczyć podejściem. –

Odpowiedz

35

Jeśli działa na Intel Core 2 Duo można podwoić szybkość buduje poprzez zmianę opcji config DarwinPorts znaleźć tutaj:

/opt/local/etc/macports/macports.conf

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

byłem kopać siebie, gdy odkryłem to po tym, jak przebudowany gcc;)

ta opcja pozwoli Ci korzystać z obu procesorów do budowania pakietów.

+0

dzięki za napiwek! mój również został skomentowany! – ennuikiller

+7

Czy ktoś może to potwierdzić? Komentarz do tego pola dla mnie mówi "Ta wartość # może być ustawiona na 0, więc liczba równoczesnych zadań make zostanie ustawiona na # liczba rdzeni procesora, które są automatycznie wykrywane, lub liczba GB pamięć plus jeden, w zależności od tego, która wartość jest mniejsza. "... więc jeśli nie wykryje się wykrycia CPU lub masz <2 GRAMy RAM, powinno to już być właściwe. – Trenton

+2

Sprawdź to dla siebie. Tak jak ja to zrobiłem. Otwórz Monitor aktywności, kliknij CPU i obserwuj różnicę aktywności każdego rdzenia, gdy zmieniasz opcję podczas tworzenia. – galaxywatcher

8

"zamrozić os"? Czy mógłbyś to sprecyzować? Jakie pakiety próbowaliście zbudować na jakiej wersji OS X na jakim komputerze?

Z mojego doświadczenia wynika, że ​​MacPorts generalnie działa poprawnie w prawie każdej obsługiwanej konfiguracji, w moim przypadku od 256 MB Pismo G3 (rok 2000) z 10.4 w górę za pomocą najnowszego dwurdzeniowego Intel iMac na 10.5. Musisz być jednak cierpliwy: może to zająć dużo czasu, szczególnie jeśli istnieje wiele zależnych pakietów, co jest jedną z wad korzystania z menedżera pakietów, takiego jak MacPorts lub Fink. Plusem jest to, że zazwyczaj masz dużo bardziej kontrolowane i, z nadzieją, testowane środowisko, niż gdy instalujesz samodzielnie pakiety ze źródła. A jeśli jeszcze tego nie zrobiłeś, upewnij się, że zaktualizowałeś system MacPorts: wersja 1.8.0 została właśnie wydana i ma kilka ważnych usprawnień, w tym lepszą obsługę uniwersalnych kompilacji.

+0

+1 ... aby zagrać z Nedem, jeśli to, co budujesz, ma wiele zależności od pakietu (a te pakiety mają zależności itd.), Będziesz czekał długo, aby skompilować swoje rzeczy. –

+0

przez zamrożenie os Chodzi mi o to, że przestaje odpowiadać przez kilka sekund. Używam OS X 10.6 na Core Duo 2 MacBook Pro z pamięcią 4GB. Wystarczająco dużo, aby poradzić sobie nawet z najbardziej intensywnymi procesami cpu/mem. Porównuję macporty z yum, z których korzystałem od dłuższego czasu na systemach Linux, i znowu wydaje się, że komputery Macport są znacznie mniej zwinne .... – ennuikiller

+0

Komputer okresowo przestaje odpowiadać, ponieważ wiele buildów i instalacji ma bardzo bolesne wzorce IO i jest to wąskie gardło w przypadku dyskowych operacji wejścia/wyjścia. Nie ma nic wspólnego z procesorem ani pamięcią. Nie jest tak źle z yum, ponieważ yum instaluje prekompilowane pakiety binarne, a nie je buduje. –

4

Nie mam nic przeciwko oczekiwaniu, aż porty Mac będą budować ze źródeł na najnowszych pakietach. Ale dlaczego nie wykorzystać całej tej mocy obliczeniowej i zaoferować użytkownikom opcję, aby kompilacja była automatycznie przesyłana z powrotem do MacPorts lub lepiej, aby była mieszana i oferowana w trybie peer-to-peer innym użytkownikom MacPorts, którzy mogą wybrać opcję "turbo".

+7

Prawdopodobnie dlatego, że w dzisiejszych czasach ludzie (ja włącznie) są zbyt paranoiczni, aby zaufać binarnemu od nieznajomego. Zabawne jest to, że większość z nas nigdy nie zadaje sobie trudu zaglądania do kodu źródłowego, który budujemy codziennie ... –

+2

Znalazłem to pytanie, zastanawiając się, dlaczego to buduje, zamiast instalować plik binarny, ponieważ ta "odpowiedź" zastanawia się ... ufajcie, cóż, jeśli ufamy drzewu źródłowemu macports, to nie widzę powodu, aby nie ufać, powiedzmy, kompilacji rzeczy wykonanej w macportach.To wymaga, aby ludzie z Macport mieli zasoby (sprzęt, czas itd.) Do budowania rzeczy (na różne platformy), ale ... może jest jakiś pośredni sposób? Wiem, że wolałabym instalacje binarne, pod warunkiem, że istnieje pewien podobny poziom zaufania. Jest na pewno nie mniej bezpieczna (z natury zresztą) niż ta, na którą nie patrzy źródło. – lindes

+0

Nie w oparciu o p2p, ale tak jest od 2.0, nie wszystkie pakiety są dostępne z powodu dostępności licencji i zasobów (buildbot musi przetworzyć plik, zanim archiwum będzie dostępne). Archiwa są podpisane, zob. http://packages.macports.org – anddam

5

MacPorts używane tylko do budowania ze źródła, co może prowadzić do różnicy kilku rzędów magnitudo w porównaniu do systemu pakietów, który pobiera pliki binarne. Zastanówmy się na przykład w przypadku dużego pakietu, który zajmuje kilka godzin, i porównajmy go z czasem pobrania go jako archiwum o wielkości kilkudziesięciu MB.

MacPorts używa narzędzi Apple do budowy i dodaje tylko nieznaczny narzut do tego samego czasu budowy, który można uzyskać poza MacPorts, im większy pakiet, tym mniejsza różnica. Jeśli zauważysz dużą różnicę podczas budowania programu poza MP, powinieneś złożyć szczegółowe informacje o numerze issue tracker.

To powiedziawszy, widzę, że pytanie jest dość stare, ponieważ 2.0 istnieje wsparcie dla archiwów binarnych -cf. Changelog - istnieje repozytorium obsługiwane przez macosforge z buildbotami, które generują podpisane archiwa, a domyślnie jest pobieranie tych archiwów binarnych zamiast budowania ze źródeł (które można wymusić przy użyciu flagi -s). Obecny interfejs użytkownika jest bardziej podobny do menedżerów binarnych, takich jak apt-get, z możliwością łatwej zmiany konfiguracji i opcji kompilacji.

Powiązane problemy