1 |
On Sun, Nov 20, 2011 at 2:07 PM, <v_2e@×××.net> wrote: |
2 |
> Hello! |
3 |
> |
4 |
> On Sun, 20 Nov 2011 09:07:33 -0500 |
5 |
> Michael Mol <mikemol@×××××.com> wrote: |
6 |
>> |
7 |
>> I'll venture a guess that it may have approached 9GB either with some |
8 |
>> short-lived files, or *would* have approached 9GB with a different USE |
9 |
>> flag or other configuration combination. |
10 |
>> ... |
11 |
>> Ok, then I'll narrow my guess to the size required being dependent on |
12 |
>> USE flag combinations. |
13 |
>> |
14 |
> Yes, I thought so too, but I use the same set of USE flags for quite |
15 |
> a long time, and previous versions of LO really needed the stated |
16 |
> amount of free space. At least, more than 6 GB. And the last version |
17 |
> (3.4.4) not only needs about a half of the stated space, it needs |
18 |
> *less* space than the previous versions. |
19 |
> It may mean that the newer version is *substantially* reworked |
20 |
> though, which is very good. :) |
21 |
|
22 |
I forget the name of the tool that predicts compile times based on |
23 |
package sets and USE flags. Perhaps it could be expanded to collect |
24 |
data and predict disk requirements? It'd almost require stracing the |
25 |
compile process tree or FAMing the build directory tree, though; |
26 |
polling with 'du' might miss a peak usage point. (And would certainly |
27 |
slow things down) |
28 |
|
29 |
-- |
30 |
:wq |