backend makefiles

Matthias Benkmann haferfrost at
Sun Aug 19 04:57:07 PDT 2001

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 
it's 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 
stuff wrong.

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 
be 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 
the 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 
instructions 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 
and gzip-current/ for the unpacked package directory. Now if you want to 
update 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 
allow 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 
reimport 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 
file with the PACKAGES= line that just lists all packages the user has 
selected. 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 
the 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.


For sale: Parachute. Only used once, never opened, small stain.

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