On 10/07/2013 07:17:08 AM, Kirk Terrell wrote:
On 10/04/2013 08:09 AM, Andrew Bradford wrote:
What niche is the CLFS embedded targeting - a raspPI can run a full
blown desktop distribution?
What niche is LFS itself targeting given that Slackware still exists
and predates it?
Determining what niche is hard but is a good question. I think
CLFS's
embedded book should show how to build a busybox (or similar) based
rootfs without needing to boot or chroot (like the main CLFS book).
Attempting to cross compile the whole of BLFS may not end well.
A better question, though, given that openembedded seems like the
predominant build system for doing this activity, would be should
CLFS
embedded stop trying to show how to do a build like this by hand but
instead focus on teaching people how to use openembedded?
No.
My first
impressions, both a few years ago when I looked at it and then again
recently, of openembedded or other bitbake build systems is that it's
very powerful but horribly documented on the how, why, and what
happens
or how to expand it.
It's not just the documentation, it's the design. Board files and
package files are not cleanly separated. I wanted to tell it "give me a
basic build environment for these five boards" and "natively build this
set of packages on whatever board you're running on", and it just
doesn't think like that.
The learning curve for how to leverage oe/bitbake
effectively beyond just using Angstrom or similar is steep but it
doesn't need to be.
For instance, are there bitbake receipes/layers for making a
musl/busybox rootfs? Would that be valuable? Would a well written
documenation saying wtf is going on within the build process be
useful?
Or am I off on a tangent?
Are you going to do the same for buildroot?
I'm kind of getting burned out with CLFS embedded lately. There's a
lot
that needs to be updated and I've been getting frustrated a lot
lately
by that. There was a good year or so break in my contributions to
CLFS
embedded and not much happened during that time. The developer
interest
in keeping the book up to date seems to be very low.
I did a build system that creates cross compilers, uses them to build
the simplest build environment capable of rebuilding itself under
itself, and then boots under qemu to build more packages natively there.
I got the "simplest build environment" down to seven packages (and hope
someday to get it down to four) but the toolchain I'm using is very
stale at this point (the last GPLv2 release of gcc/binutils) and LLVM
is still cooking.
Linux From Scratch has never been a directly deployable system because
it has no apps. Instead it provides a build environment within which
you can install arbitrary additional packages via "configure;make;make
install". (And blfs documents the dependencies for doing so for lots of
common packages.)
Presumably, the point of cross linux from scratch is getting that build
environment up and running on an arbitrary target. You can always trim
the deployed system later by deleting files or populating a new chroot.
I'm not sure if an openembedded tutorial is a CLFS project - but if
you managed
it your praises would be sung far and wide.
I want to get openembedded to build its packages and install them into
the current filesystem (or a new chroot). Build them with whatever
toolchain is in the host path for whatever architecture we happen to be
running.
It's really not set up to do that.
I skimmed thru an article in Linux Journal this month that was a
tutorial on how to put the debian distribution on a different ARM
board. Another option might be to focus on how to marry an existing
distribution with a board to get it up and running.
I'm very much interested in doing this for my aboriginal linux project.
I already have automated build control images that let you boot qemu
with a bundle of source code and shell scripts that automatically build
stuff instead of just giving you a shell prompt, and I've decided that
package management is beyond the scope of my project and what I really
need to do is bootstrap an existing distro in a linux from scratch
style environment.
Unfortunately, running the source version of debootstrap under LFS
(without grabbing prebuilt binaries for an unknown architecture) turns
out to be hard. Same for gentoo and fedora, plus variants like ubuntu,
funtoo, and suse. Haven't tried slackware yet... Every distro assumes
it's building under the previous version of _that_distro_, and is full
of implicit assumptions about how the environment's set up and that the
repository will be initialized by extracting a magic tarball from
somewhere.
A project to bootstrap distros under Linux From Scratch without
downloading a prebuilt binary chroot but actually doing so from source
would be awesome. And hard.
Rob
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
