On 6/15/20 2:09 AM, Kevin Buckley via lfs-dev wrote:
On Sat, 13 Jun 2020 at 20:46, Bruce Dubbs via lfs-dev
<lfs-dev@lists.linuxfromscratch.org> wrote:
In the last few weeks, the LFS editors have been working on a major
overhaul of LFS. This work can be reviewed at
http://www.linuxfromscratch.org/~bdubbs/cross2-lfs-book/
Was there an SVN reference (branch) to pull the sources from?
We welcome comments and criticisms large and small.
-- Bruce
These comments (or maybe criticisms - your interpretation: your rules)
based on a very quick speed read: please take that into consideration
when deciding.
We appreciate your input.
I'd like to see the "cross-compiling 101" sections, so
Introduction
Toolchain Technical Notes
General Compilation Instructions
in "chapter" 5, separated out from the package build sections there.
We can possibly put a header in the table of contents like we do for
Java in
http://www.linuxfromscratch.org/blfs/view/stable/general/prog.html, but
the new Chapter 5 is now only 8 pages long. A separate chapter doesn't
make sense to me.
Appreciate they would make for a very small introductory chapter
but it somehow feels wrong as it is.
Not sure if I'd favour the Pass1 and Pass2 sections all being within
the same chapter or not though, or how one would entitle a chapter
that just contained just those five package builds, plus yet another
Introduction.
The pass1/pass2 titles are all in Part III. In the full book there are
really three builds for some packages. The -pass titles are really to
emphasize that the same packages are being built with different
procedures fo rthe creation of the tools.
I am also aware that Ninja and Meson are still only "required" for
the SystemD version, but that LFS has decided to build packages
in the SysV revision with them, even though all required packages
can still be built using an Autotools-based approach.
(I 'm sure that claim is soon to be rendered invalid though?)
In BLFS is is hard to get away from meson and ninja. A lot of packages
are going to those (and in my opinion, not fast enough). LFS has never
been about minimalism. If we did that we could omit things like man
pages and vim. It is about building a solid base system from which a
user can build the real applications that are needed.
I appreciate there's a perception that the SysV and SysD books
should align as much as possible, indeed I've even got some
packages re-ordered on the basis of that view, but I'm less
convinced that the SystemD tail should wag the LFS dog.
It's doesn't really. When we had separate source it was a major effort
to keep both books in sync. Over 90% of the two books are common so it
makes sense to keep them together.
Given that LFS used to start from the view that one only built
what was needed to build the LFS-system, and never warming
to the systemd camp fire, i've always felt Ninja and Meson to be
a kind of feature-creep and so was wondering if that could be
made more explicit, so that people could see that Ninja and Meson
could happily be left out until BLFS.
(Though there's no getting away from them there: more's the pity!)
I generally don't do much with systemd either. In BLFS there are over
100 packages that use meson and over 100 others that use ninja.
Recently I've become very unhappy with autotools because configure at
-j1 takes as long as the make phase. These newer tools are really better.
Then again, I could make the same claim for Intltool and a
couple of other packages related to it.
Looking forwards to trying it out though,
Again, thanks for your input.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
