SUMMARY: alfs direction

pak_lfs at pak_lfs at
Fri Nov 25 14:27:06 PST 2005

Thomas Pegg wrote:
> It's breaks down like this:
> src_unpack - Unpacking and patching, etc here.
> src_compile - configure and make
> src_install - make install and any other install commands
> src_test - commands needed to test a package (not used very often in
> gentoo)

When trying to script my own builds I researched pretty much the build
formats from the other distros, mainly gentoo, sourcemage, and ROCK/T2.
It seems pretty much everybody agrees that in the end 99% of packages
can be decomposed to: * unpack, 

                                   * prepare (patching, if autotools package
                                                { run autoconf if from CVS, 
                                                 configure } )
                                   * build (make, optionally make check)

                                   * install (make install / possible package

                                   * configure ( run configuration scripts,
                                                   install config files / init
                                                                  scripts etc) 

The nice thing with this abstracting of commands into stages, is inheritance
and dynamic binding like in OOP. Let 's look at a bash-based implementation:

We have a directory layout like this:

                             prepare build  install configure

                             prepare build install configure

                          .parent ->  ../../classes/autotools

This way, if you want to install kde-libs, you just call 
'execute kde-libs install' and it pulls in the right 'stage code'  
from autotools (prepare etc).

Now if you want to move from a standard autotools profile to a standard
scons profile you just rearrange .parent to point to scons and ideally
touching nothing else!

Gentoo chose to do this instead by mixing their shell code with python
and have the python code parse part of the things the shell script puts
into environment  variables and vice-versa but I don't think we either
can  or want to produce something as complex as portage/gentoo distutils.

> It may not be real fine grain control, but there is some control there.
> You can have client tell the server to only run one piece of it at a
> time especially useful when debugging. Like with Gerard just posted
> about OpenOffice, the client would just tell the server to run only the
> src_install function, instead of re-running the whole thing. Now more
> fine grain control to say run only one command out of the function,
> would take some more work.
> I think it's a good format that gives you control similar to what is
> currently in the xml based profiles, but without the xml.
> Thomas

As soon as you can usually customize these standard 'stages' even
further by optional features (USE flags) - e.g., have it execute or not
the test suite depending on whether the string "test" is within the $USE
env var, I personally don't need further control, since that means loosing
*all* reusability/inheritance and having to type everything manually.


____________________________________________________________________ - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. - free email service for the Greek-speaking.

More information about the alfs-discuss mailing list