We were saying "-jN means using N cores (or N threads)". This is
completely wrong. "-jN" only tells the building system to run N jobs
simultaneously, but each job can start their own subprocesses or threads
and there is no way for the building system to know how many
subprocesses or threads a job will start.
This caused a lot of misunderstandings and encouraged users to wrongly
blame building systems.
Fix the description of -jN, and add how to use cgroup to control the
usage of CPU cores and system RAM.
On a systemd-based system, systemd is the cgroup manager and manually
operating on cgroups may puzzle systemd. So use systemd-run for
creating and setting up cgroup. On a sysv-based system create and set
up the cgroup manually.
scripting.
If combine_install_with_separate_uninstall hangs, a user can press the
Enter key, or remove the test with a sed.
Thanks goes to Rainer Fiebig for the report.
The rustdoc program is a part of rustup default install. And it was
installed with previous rustc releases even if we didn't specify it in
build.tools (so it's in the "contents and short descriptions" section).
But with rustc-1.69 it's not installed if we don't explicitly add it
into build.tools.
It's needed by "cargo doc" command (I use it when I develop Rust
crates), and also some BLFS packages (at least, the testsuite of
librsvg).
Add rustdoc into build.tools so it will be built and installed.
The most likely reason to rerun a scripted build of rust is that
something failed during build. But since this directory is created at
the beginning of the script, the script will fail early cresting the
directory.
Of course, now, there is no protection against erasing a successful
build when rerunning with different options.
- Add `locked-deps = true` and `vendor = true`. These allows building
the package w/o downloading from crates.io (the bootstrap compiler
still needs to be downloaded though), and eliminates the necessity of
using a DESTDIR installation. Note that in LFS we already do DESTDIR
installation for ncurses so we won't lose too much educational
material.
- Add `description = "for BLFS &version;"` so BLFS version will show up
in the output of `rustc --version`.
- Remove `rpath = false`. With rpath we can skip the modification of
`/etc/ld.so.conf` file. Note that rpath is coded as
`$ORIGIN/../lib`, so if you run `ldd` on the executable in the build
directory, it will show the path to the build directory; but if you
run `ldd` on the installed executable, it will show the correct path
to the installed library. See `man ld.so` for more information about
`$ORIGIN`.
And, adjust LIBSSH2_SYS_USE_PKG_CONFIG according to if libssh2 is
installed. Export it earlier so x.py build and x.py install will use
the same LIBSSH2_SYS_USE_PKG_CONFIG value. This can reduce some
repeated building process.
When measuring the SB unit, I used a terminal with "time { ... }".
When measuring LLVM and rust SBUs, I redirected output. It seems
the gnome terminal is very slow, and when redirecting the output of
the "time" command above, the SB unit goes from 119s down to
86s.
When scripting, this flag makes the linking silently ignored... This
leads to headaches when one thinks he is using a just built new
version of rust and the old version is still used...
