From: Ned Ludd <solar@gentoo.org>
To: Heiko Wundram <heikowu@ceosg.de>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: emerge suggestions
Date: Wed, 08 Sep 2004 20:03:16 -0400 [thread overview]
Message-ID: <1094688196.5889.476.camel@simple> (raw)
In-Reply-To: <200409090146.45636.heikowu@ceosg.de>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
On Wed, 2004-09-08 at 19:46, Heiko Wundram wrote:
> Am Mittwoch, 8. September 2004 18:43 schrieb Chris White:
> > How are you going to effectively measure the times?
>
> IIRC, there once was a proposal to do this using bash-units. Each product in
> the tree gets assigned a bash unit, which is a floating point number >0 which
> measures how long compilation takes relative to compiling some certain
> version of bash.
>
> Now, all that needs to be done is to measure package compilation and merging
> time, divide by the number of bash units this package has, and you get an
> estimate on the time for a bash unit on this computer. The more packages you
> merge, the finer this number will become by simply averaging it out. Of
> course, this does not take into account changing the LDFLAGS (which should
> make up for the biggest part of different merge times), or CFLAGS (which
> might also change timing by varying optimization levels and swap
> requirement). But, anyway, these numbers don't change anything about the
> underlying unit, which should be to a large extent platform and machine
> independent.
To complex and still wont account for various USE= & FEATURES= flags,
gcc versions and loads on said server that's building XYZ. It's
therefore sorta a waste of all of our time and bandwidth to continue
this thread when we already know we are going to all come to the same
conclusion in the end that said functionality will never be accurate.
>
> I don't know when this proposal came up, I read about it on some forum, some
> time ago.
>
> Heiko.
>
> --
> gentoo-dev@gentoo.org mailing list
--
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-09-09 0:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 15:40 [gentoo-dev] emerge suggestions Philippe Trottier
2004-09-08 15:47 ` [gentoo-dev] " Sebastian Bergmann
2004-09-08 16:03 ` Athul Acharya
2004-09-08 16:43 ` Chris White
2004-09-08 23:46 ` Heiko Wundram
2004-09-09 0:03 ` Ned Ludd [this message]
2004-09-09 1:01 ` Heiko Wundram
2004-09-09 13:16 ` Chris Gianelloni
2004-09-09 16:32 ` Danny van Dyk
2004-09-10 9:29 ` Marcus D. Hanwell
2004-09-09 0:19 ` Thomas de Grenier de Latour
2004-09-09 1:01 ` Daniel Goller
2004-09-08 20:10 ` Chris White
2004-09-09 5:06 ` Alin Nastac
2004-09-09 13:13 ` Chris Gianelloni
2004-09-09 2:12 ` Joseph Booker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1094688196.5889.476.camel@simple \
--to=solar@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=heikowu@ceosg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox