Sounds like the best bet would be an estimate like install space + (build space * fudge factor), with a fudge factor starting at perhaps 1.5 and adjusted by subsequent experience and reports.
> On Aug 10, 2016, at 21:32, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Aug 10, 2016, at 8:28 PM, Lawrence Velázquez <lar...@macports.org> wrote: >> >>> On Aug 10, 2016, at 9:04 PM, Ryan Schmidt <ryandes...@macports.org> wrote: >>> >>>> On Aug 10, 2016, at 5:15 PM, Mojca Miklavec <mo...@macports.org> wrote: >>>> >>>> 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. >> >> This could be helpful, but it wouldn't provide information about the >> *maximum* disk space required by a build, which could easily surpass the >> size of the final build products. > > That's true. The buildbot could also record the size of the work directory > before it's cleaned up. That wouldn't be 100% accurate either, since it's > possible for a build to create temporary files that are cleaned up during the > build, such as the gcc ports, but it would be a place to start. > > _______________________________________________ > macports-users mailing list > macports-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users > _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
