43

Building from source outside of macports is a breeze. Building with macports takes forever and seems to freeze the os every so often. Is this typical behavior? Although it seems like a nice packaging tool for os x, if I have to go through this pain every time during every install I think I'll do without it.

ThinkingStiff
  • 64,767
  • 30
  • 146
  • 239
ennuikiller
  • 46,381
  • 14
  • 112
  • 137
  • 3
    I don't consider this question answered below. Contrast the performance of macports against any other package manager such as apt-get it must be of the order of 100 times slower. – user363349 Nov 01 '11 at 12:22
  • 2
    If you don't have an actual test you shouldn't use arbitrary quantities "100 times". – anddam Sep 03 '12 at 08:44
  • @user363349: It's not fair to compare macports to apt-get; Linux ecosystem repositories typically deal in pre-compiled binaries. Macports compiles every time from source. The difference in speed can be explained by the approach. – Chris Hatton Mar 13 '13 at 12:59
  • I agree with @Augmental Macports is slow because it compiles from source, basically it's meant to work like this. It is meant to be this slow. If you don't care about source use brew! – user363349 Mar 13 '13 at 17:50

4 Answers4

36

If you are running on an Intel Core 2 Duo you can double the speed of your builds by changing the Macports config option located here:

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

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

I was kicking myself when I discovered this AFTER I rebuilt gcc ;)

This option will allow you to use both cpu's for building packages.

galaxywatcher
  • 821
  • 1
  • 10
  • 15
  • 8
    Can anyone confirm this? The comment on this field for me says "This # value may be set to 0 so the number of simultaneous make jobs will be set to # the number of CPU cores that are automatically detected, or the number of GB # of physical memory plus one, whichever is less."... so unless CPU detection is broken or you have < 2 gigs of ram, it should already be doing the right thing. – Trenton Dec 20 '09 at 17:26
  • 2
    Test it for yourself. As I have done. Open up Activity Monitor, click CPU and watch the activity difference of each core when you vary the option during makes. – galaxywatcher Dec 21 '09 at 09:08
  • The comment says *may be set to 0* but by default it's commented out --- what is the **default** value is it 0, is it 1, etc? – Justin Jenkins Jan 23 '12 at 21:47
  • 2
    According to http://guide.macports.org/chunked/internals.configuration-files.html, the default value is 0 which causes a runtime autodetection to use all available processor cores. – Martin Aug 30 '12 at 07:01
  • In my case I had to set this variable to 1 (default is 0). I was trying to build boost. – Felipe Mar 20 '14 at 10:28
  • 2
    The default value is 0. This means **autodetect** as per @Trenton comment. All(4) cores of my CPU are being used during the compilation. Checked on a fresh installation of MacPorts 2.3.3. – averasko Nov 28 '14 at 05:20
8

"freeze the os"? Can you be more specific? What packages were you trying to build on what version of OS X on what machine?

In my experience, MacPorts builds generally work correctly on almost any supported configuration, in my case ranging from a 256MB Pismo G3 (year 2000) running 10.4 up though a recent dual-core Intel iMac on 10.5. You have to be patient, though: it may take a long time especially if there are a lot of dependent packages, which is one of the drawbacks of using a package manager like MacPorts or Fink. The upside is that you generally have a much-more controlled and, one hopes, tested environment than if you installed individually packages from source yourself. And, if you haven't already, make sure you update to the latest MacPorts: 1.8.0 was just released and has some important improvements, including better support of universal builds.

Ned Deily
  • 83,389
  • 16
  • 128
  • 151
  • +1... to chime in with Ned, if what you're building has a lot of package dependencies (and those packages have dependencies, and so on), you'll be waiting a long time to get your stuff compiled. – Shaggy Frog Aug 29 '09 at 22:13
  • by freeze the os I mean it becomes unresponsive for a few seconds. I'm running os x 10.6 on a core duo 2 macbook pro with 4gb mem. More than enough to handle even the most cpu/mem intense processes. I'm comparing macports to yum which I've used on linux systems for quite some time, and again macports just seems much less agile.... – ennuikiller Aug 29 '09 at 22:26
  • Your computer periodically becomes unresponsive because a lot of builds and installs have very bursty IO patterns and it is bottlenecking on Disk IOs. It has nothing to do with CPU or memory. It is not nearly as bad with yum because yum is installing precompiled binary packages, not building them. – Louis Gerbarg Aug 29 '09 at 22:45
  • 3
    Well, yeah: if you're comparing installed pre-built binary packages to building packages from source - sure it's going to be slow! It would be nice if MacPorts did provide prebuilt packages but the infrastructure and testing to do that is more complex and not in the spirit of ports. Fink *tries* to do that - in the spirit of Debian apt-get - but they really don't have the resources to do it so they have a hybrid system of both source-only and binary packages with most of the binary packages not getting updated very often. – Ned Deily Aug 29 '09 at 22:59
  • And, not to sound glib, but, like many multi-person open-source projects, I bet either the MacPorts or Fink projects could use and would welcome more help. – Ned Deily Aug 29 '09 at 23:07
  • You can enable archive mode on your machine and MacPorts will look for archives from the same architecture that you drop in there before attempting to compile. You have to dump in the archive for now. – Jeremy L Oct 14 '09 at 22:02
  • Using archive mode isn't very useful on the same machine unless you accidentally uninstall some current versions, is it? It can be more useful if you want to install the same packages on multiple machines at the same OS X and MacPorts version level and with the same architecture. Last time I tried, sharing universal architecture archive was messy because the architecture name was used in the path names; perhaps that has been fixed. – Ned Deily Oct 14 '09 at 23:50
5

MacPorts used to only build from source and this can lead to a difference of several orders of magnitudo when compared to a package system that fetch binaries. Consider as example the case of a somehow big package that takes few hours to be built and compare this to the time of downloading it as an archive having a size of a few tens of MBs.

MacPorts uses Apple's tools to build and it only adds a negligible overhead to the same build time that you would get outside of MacPorts, the bigger the package, the smaller the difference. If you experience a huge difference when building a program outside of MP you should file a ticket on the issue tracker with the details.

That said I see the question is quite old, since 2.0 there's support for binary archives -cf. Changelog- there's a macosforge supported repository with buildbots that produce signed archives and the default is to fetch these binary archives rather than building from source (that you can force using -s flag). The current user experience is more similar to binary managers like apt-get, with the ability to change configure and build options quite easily.

anddam
  • 1,322
  • 1
  • 12
  • 12
5

I don't mind waiting for Mac Ports to build from source on the latest packages. But why not harness all this processing power and offer users the option to let the build be automatically uploaded back to MacPorts or better still be hashed and offered peer-to-peer to other MacPorts users who can choose a 'turbo' option.

diceman
  • 59
  • 1
  • 1
  • 8
    Probably because these days people (myself included) are too paranoid to trust a binary from a stranger. The funny thing is that most of us never bother to look into the source code we build everyday.... – Lester Cheung Dec 21 '10 at 05:48
  • 3
    I found this question when wondering why it builds rather than installs a binary, as this "answer" wonders... As for trust, well, if we trust the macports source tree, then I see no reason not to trust, say, a macports-executed build of things. That does require the macports folks to have resources (hardware, time, etc.) to build things (for various platforms), but... perhaps there's some intermediate way? I know I'd prefer binary installs, provided some comparable degree of trust is there. It's surely no less safe (inherently, anyway) than source one doesn't look at. – lindes Jun 24 '12 at 17:05
  • Not on a p2p basis but this is the case since 2.0, not all packages are available due to license and resources availability (the buildbot needs to process the file before the archive is available). The archives are signed, cf. http://packages.macports.org – anddam Sep 03 '12 at 08:40