backend makefiles

Matthias Benkmann mbenkmann at
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
NORMAL_CONF   =--prefix=/usr



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 
for instance.

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

make all 

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

make update

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
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list