Idea: Port Checks for Disk Space Before Compiling?

Ryan Schmidt ryandesign at
Wed Aug 10 18:04:36 PDT 2016

> On Aug 10, 2016, at 5:15 PM, Mojca Miklavec <mojca at> wrote:
> On 10 August 2016 at 23:58, Jean-François Caron wrote:
>> This keeps happening.  My laptop’s hard drive has only a few (~5) gigs of space left, and I foolishly decide this is a good time to upgrade clang.  Turns out clang needs infinite space (kidding) to compile, so about 30 minutes into the compilation my computer tries to warn me that the disk is nearly full but it’s already too late and I can’t scramble to make space before everything starts crawling.
>> This might be specific to clang only, but is there a way for ports that need a LOT of free space to check before trying to compile?
>> I know the obvious solution is to keep more free space on the disk, which is a good idea generally, but these SSDs get pretty expensive!  It feels extra stupid that all this time I have like 5 Gb of RAM left unused, but that’s a different issue.

I have this problem too. Clang needs around 20GB free space. When I find I'm running low on space, I "Control-Z" the port install, to pause it and give me time to clear off some space. Then type "fg" to bring the paused task back into the ForeGround and resume running it.

It's a good idea to keep at least 10% of your disk free. macOS is much happier when you do. (Do as I say, not as I do.)

> The major problem is that there is basically no way to predict how
> much space an installation of a port from source might need (one might
> be able to do some heuristics based on old build logs from the
> buildbot or so, but that might be quite some work for very little gain
> and it won't work well for non-default variants etc).

It would be easy for the buildbot to record the size of the installed package, even if the package isn't distributable, and could submit that information to our hypothetical new web site, from which MacPorts could query it.

> When fetching the binary archives, we could get the information about
> the size of the tarball and I'm pretty sure one could do something to
> compute and calculate the size of the extracted package. But
> estimating the size of the build from source is going to be difficult.

Good idea.

More information about the macports-users mailing list