Actual tool design

Gerard Beekmans gerard at
Sun Jun 25 14:17:23 PDT 2000

I think we should skip all this talk on what we *can* do. If we do it
properly all those things will just be things you shove in a profile.

So we need to design a tool that needs a profile and runs according to

The first question that comes to my mind is how much information should
that profile contain. Take the "creating directories" subsection of the
LFS book. Do you put even such basic information in a profile (so that
it can be overridden) or do we put such basic information in the tool
itself and have a profile override it.

To clarify imagine this (this is NOT what I want it to look like at all,
but it explains my thoughts in the best possible way):

do we put "cd $LFS; mkdir bin sbin root home" in the tool's
program/script and override it in a profile in a way like this:

Override_Dirs = TRUE
Override_Dirs_Data = cd $LFS; mkdir your own dirs here

Or do we put in the tool a line like:

and put the Override_Dirs_Data line in the profile like above (change
name though since in this case you're not overriding but you get the
point), but without a OverrideDirs = TRUE line 

Oh, if we put it in the tool a line like this must be present in the
tool too:
Check_if_Dirs_Are_Overridden_In_Profile <--- find the Override_Dirs var.
and see if it is set to TRUE or FALSE. Of course, if FALSE, use the
tool's default built-in dirs, else the override_dir_data values.

These things are quite important to discuss now because we need to
decide on the structure of the tool and the profile syntax before we
build anything here. I don't want to change the syntax of the profiles
10 times because it doesn't work too well anymore with the tool itself.

My proposal is this:

#In the tool itself
Default_Dir_Values = bin sbin root home
if ! Check_Override_Dir
	cd $LFS; mkdir Default_Dir_Values
#end tool

and profile would contain:

# start profile file


#define Override_Dir TRUE

#ifdef OverrideDir
#define Default_Dir_Values bin sbin root home tmp etc home lib mnt


#end profile file

(perhaps header file syntax is a good way to go. I just prefer it but
isn't necesarrily the best/easiest way to go. Bryan suggested XML type
profiles. That might be an idea as well. Why not support multiple
profile syntaxes so the user can choose how he/she wants to write it.
The first line of a profile file should contain a 'magic number' type of
thing so the tool knows what kind of syntax to parse).

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Mail archive:
IRC access: server: port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the alfs-discuss mailing list