mbenkmann at gmx.de
Tue Aug 21 02:49:15 PDT 2001
This is a resend because of problems with my other account.
I am just working on my own system for automating the building of an LFS
system so I thought I'd subscribe here and post what I'm doing in case
of interest to ALFS developers. I have to mention that all I know about
ALFS is from the introduction and roadmap on the ALFS website (maybe it
would be time to update that, it's rather old), so excuse me if I get
My system is purely make-based and does not deal with user interfaces,
network-installation etc. It's only concerned with the actual building of
an LFS system, so it's not an alternative to ALFS. I think it could even
used as a backend system for ALFS.
Unlike LFSmake, I don't have everything hardwired in a big makefile. Quite
the opposite is true, my master makefile does not know anything about
package specifics. Instead, packages are configured with 1 or 2 files
(following example is for gzip):
a) standard.conf: This file looks like this
DEPENDENCIES=glibc make sed ...
COMMON_CONF =cd $(PACKAGE_DIR) && ./configure
COMMON_MAKE =$(MAKE) -C $(PACKAGE_DIR)
COMMON_INSTALL =$(MAKE) -C $(PACKAGE_DIR) install
b)If the program need some special instructions that don't quite fit in
configure; compile; install frameword, a file LFSmakefile can be added
which looks like this:
ifndef prechroot #*** NORMAL INSTRUCTIONS ****************************
else #*************** PRE-CHROOT INSTRUCTIONS ************************
cp $(LFS)/usr/bin/gunzip $(LFS)/usr/bin/gzip $(LFS)/bin && \
rm $(LFS)/usr/bin/gunzip $(LFS)/usr/bin/gzip ;\
The targets pre_configure, post_configure,pre_install,pre_compile and
post_compile may also be used. pre_configure could contain sed
I order to install the gzip package you just throw standard.conf,
LFSmakefile and a symlink Makefile->/path/to/MasterMakefile into
/usr/src/gzip together with gzip-<version>.tar.bz2. Then a simple
make prechroot=yes all
will perfrom pre-chroot installation and
will perform normal installation (inside chroot or on the finished
The Makefile also offers the targets unpack, configure,compile,install. So
you can work with the same granularity as the LFS book (which is the major
reason why I don't like LFSmake; it doesn't allow this)
The above does not yet deal with dependencies. Dependencies will be (I
haven't done this part yet) another target called deps, so if you do
installation out of order you should do
make deps all
which will ensure that the prerequisites are built first.
You will notice that in no place the name of the gzip archive or the
version number is mentioned. And the location of the ./configure script is
only referenced as $(PACKAGE_DIR) without defining this variable
explicitly. This is not an omission. The Makefile determines all of this
automatically and sets up symlinks gzip-current.tar.bz2 for the package
gzip-current/ for the unpacked package directory. Now if you want to
the package you just throw a new .tar.bz2 (or .tar or .tar.gz) into the
gzip directory and
which will detect the new archive and adjust the symlinks. So
make update all
will install the updated package. This allows you to keep different
versions of gzip in /usr/src/gzip. If you want to install the old version
again you just touch its archive and do make update again.
BTW, patch.gz, .patch and .patch.bz2 files are also detected and applied
automatically (but of course there is a also a patch target that will
you to explicitly call for this step; as I said, being able to work with
LFS-book granularity is important to me).
What I haven't mentioned yet is how to build a complete LFS system. There
will be another generic Makefile to do this which will have a config file
In this case, the user only wants to install xfree86. Because of the
dependencies however, he will get a mostly complete LFS system anyway.
Now back to ALFS. As I understand it, the ALFS profile should contain
enough information to generate the standard.conf and LFSmakefile files, so
the above system could be used as a backend for ALFS. In fact the
standard.conf and LFSmakefile files are easy to enough to parse to
into the XML profile. So ALFS could be used like a repository. A typical
use would be the following:
a) use the ALFS front end to select what type of system you want
b) "check out" appropriate standard.conf and LFSmakefiles; the frontend
sets up the /usr/src tree while doing this. It also creates the config
with the PACKAGES= line that just lists all packages the user has
The ALFS frontend does not need to do dependency checking on this list.
Handling dependencies is make's job.
c) The user chooses "build it!" in the frontend and the frontend just
executes "make lfs" to build the whole thing
d) Something goes wrong. make aborts with an error. The user leaves the
frontend and fixes the problem by adding a switch to PRECHROOT_CONF in
e) Starting "make lfs" again will continue the build (packages that have
already been built will not be rebuilt)
f) The user wants to remove the now uneeded /usr/src stuff. He fires up
ALFS frontend, which detects that a standard.conf file is different from
the profile. The user chooses to "check in" these changes. Now he can
delete the sources in /usr/src without losing his changes. The changes are
now in the profile and can be used for installing the same system again on
a different computer.
An optimist thinks that this is the best possible world.
A pessimist fears that this is true.
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss