| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
Thank you for your replies. Because there is so much in my first email,
I'll section it apart into more readable chunks.
Regarding the utility of an updated LFS bootable media...
Many various live media doesn't have everything that's needed to build
an entire alfs system. In much the same way that the existing LFS
bootable can't build a current LFS, other distribution live bootables
can't do it either. For my particular scenario, this old i586 133MHz
system needs fossils to come to life, because most of what's readily
available need a minimum of i686. I'm slowly working my way towards
getting this dinosaur of a PC running with current software, natively
compiled. Once done, my intention is to try to make a live cd. This is
a spare time project for me. I'm happy to share when it's done, however
that will be quite some time from now.
Regarding the re-calculated SBU...
I apologize for the ambiguity. To clarify, the current SBU calculation
is based on 1 out of some 110 different compiles. I would propose that
this be could be changed some when doing a complete alfs build.
Hypothetically, during the ch5 portion, time {binutils...} creates the
initial SBU value as normal. In addition, this time number is also added
to a "running sbu" file, such as sbu_toolkit.txt
When the script advances to ch5-gcc, what the user sees on the screen
would now read:
"Building target 530 GCC (estimated build time $SBU)"
While gcc is being built, it's being time{} in a very similar way as
binutils. The time output is then appended to sbu_toolkit.txt
This process of appending the time for each of the ch5 toolchain
programs is repeated. When the script reaches ch6, $SBU is re-calculated
by generating an average of the build times in sbu_toolkit.txt Using
assumptions:
build_time binutils: 5min +
build_time gcc: 20min +
build_time kernel headers: 1min +
build_time glibc: 10min+
build_time libstdc++: 1min = ch5_build_time 37min
ch5_total_sbu = (let's assume 6.5)
ch5_build_time_37min / ch5_total_sbu_6.5 = $RECALC_SBU_5.69min
The SBU has now been re-caculated using a larger data set. As opposed to
the SBU being calculated using %0.9 of the entire project, it's now
calculated at %4. We've obtained a better representative sample. The SBU
is no longer 5 minutes, it's 5m40s. Consequently, when the human looks
at the screen and it says "Building target 818 binutils (estimated build
time 11m37s)", the estimate will be more accurate. Depending on the
hardware setup, having a more accurate SBU value can easily mean the
difference between check in on the build after the night time news
broadcast vs check in tomorrow after lunch.
One reply stated SBU can't be recalculated from other ch5 packages.
Perhaps my entire line of thinking is flawed because I'm not familiar
enough with the entire process to understand why.
I can easily accept a "Brad, you're stupid... it doesn't work that way.
Trying to average the entirety of ch5 will give you a grossly skewed
SBU." If this is the case, would it be better to recalculate during ch7?
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page