| 1 |
On Wed, 2004-09-08 at 19:46, Heiko Wundram wrote: |
| 2 |
> Am Mittwoch, 8. September 2004 18:43 schrieb Chris White: |
| 3 |
> > How are you going to effectively measure the times? |
| 4 |
> |
| 5 |
> IIRC, there once was a proposal to do this using bash-units. Each product in |
| 6 |
> the tree gets assigned a bash unit, which is a floating point number >0 which |
| 7 |
> measures how long compilation takes relative to compiling some certain |
| 8 |
> version of bash. |
| 9 |
> |
| 10 |
> Now, all that needs to be done is to measure package compilation and merging |
| 11 |
> time, divide by the number of bash units this package has, and you get an |
| 12 |
> estimate on the time for a bash unit on this computer. The more packages you |
| 13 |
> merge, the finer this number will become by simply averaging it out. Of |
| 14 |
> course, this does not take into account changing the LDFLAGS (which should |
| 15 |
> make up for the biggest part of different merge times), or CFLAGS (which |
| 16 |
> might also change timing by varying optimization levels and swap |
| 17 |
> requirement). But, anyway, these numbers don't change anything about the |
| 18 |
> underlying unit, which should be to a large extent platform and machine |
| 19 |
> independent. |
| 20 |
|
| 21 |
To complex and still wont account for various USE= & FEATURES= flags, |
| 22 |
gcc versions and loads on said server that's building XYZ. It's |
| 23 |
therefore sorta a waste of all of our time and bandwidth to continue |
| 24 |
this thread when we already know we are going to all come to the same |
| 25 |
conclusion in the end that said functionality will never be accurate. |
| 26 |
|
| 27 |
> |
| 28 |
> I don't know when this proposal came up, I read about it on some forum, some |
| 29 |
> time ago. |
| 30 |
> |
| 31 |
> Heiko. |
| 32 |
> |
| 33 |
> -- |
| 34 |
> gentoo-dev@g.o mailing list |
| 35 |
-- |
| 36 |
Ned Ludd <solar@g.o> |
| 37 |
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer |
Archives