Idea: Port Checks for Disk Space Before Compiling?

[Mojca Miklavec]

On 11 August 2016 at 03:32, Ryan Schmidt <ryandesign at macports.org> wrote:
>> On Aug 10, 2016, at 8:28 PM, Lawrence Velázquez <larryv at macports.org> wrote:
>>> On Aug 10, 2016, at 9:04 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>> On Aug 10, 2016, at 5:15 PM, Mojca Miklavec <mojca at 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.

I added some very crude statistics in
    https://trac.macports.org/changeset/151264/

But:
- Ryan has to deploy those changes first
- these numbers should be collected somewhere to be of any use
- the collected statistics should eventually be integrated
into/accessible (via some api) to MacPorts

Please not that what I implemented on the link above won't help you in
any way if the builder starts building port A that depends on
clang-3.7 because clang-3.7 will then be built inside another build
and won't contain the statistics you are asking for.

For that to happen we would need to go further and add this meta info
to each dependency build step (doable though).

It also won't help you if you decide to use different variants and
will only be of partial help if your OS is not supported on the build
infrastructure. At the moment you should be able to get any clang in
binary format unless you use 10.5.

Mojca