| 1 |
Am Donnerstag, 9. September 2004 02:03 schrieb Ned Ludd: |
| 2 |
> To complex and still wont account for various USE= & FEATURES= flags, |
| 3 |
> gcc versions and loads on said server that's building XYZ. It's |
| 4 |
> therefore sorta a waste of all of our time and bandwidth to continue |
| 5 |
> this thread when we already know we are going to all come to the same |
| 6 |
> conclusion in the end that said functionality will never be accurate. |
| 7 |
|
| 8 |
The part about USE flags certainly is true, but still, I guess it wouldn't be |
| 9 |
all that hard to factor out the amount of bash units each use flag gives to |
| 10 |
the total amount of bash units for the package (simple, compile package |
| 11 |
without X, compile with X, subtract first from second, you have the amount |
| 12 |
that X adds to the package). And, calculating the bash units a program takes |
| 13 |
to compile only needs to be done once, so I don't think this is all the big |
| 14 |
hassle that you make out of it. |
| 15 |
|
| 16 |
What, IMO, makes results rather unpredictable is the problem of using a lowest |
| 17 |
common denominator machine to create the measurements for bash units, as the |
| 18 |
main thing that has to be taken into account is not the speed of the |
| 19 |
processor, but rather the memory usage of the compile, as compilation starts |
| 20 |
to drop sharply in speed when the compiler has to swap (I've experienced this |
| 21 |
more than once with PyQt, which takes longer to compile on an Athlon XP 2400+ |
| 22 |
with 256MB of RAM than on an Athlon 1300 with 1024MB of RAM, with otherwise |
| 23 |
identical systems from the software side of view). |
| 24 |
|
| 25 |
Anyway, I just wanted to tell the op that there were proposals to calculate |
| 26 |
the time, I didn't want to start a discussion about the methods... And I |
| 27 |
basically don't care if portage tells me how long a package takes to merge. |
| 28 |
|
| 29 |
Heiko. |
| 30 |
|
| 31 |
-- |
| 32 |
gentoo-dev@g.o mailing list |
Archives