Parsing the LFS book as a profile

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Fri Dec 3 06:39:42 PST 2004


Daniel Baumann wrote:

> Boris Buegling wrote:
>
>> Paralell-compiling is probably possible. Most of the time it's just 
>> adding -jN to make, isnt it?
>
> mostly, but not always.

In LFS builds, there is only one package, glibc, that takes a different 
argument. It does this: PARALLELMFLAGS=-jN
To me that's a minor issue that can easily be worked out. You'll see why 
below...

> so we will still relay on a) the 'old' profile, and b) on other, 
> seperate profiles. to be honest, this sounds not as a good argument 
> for using the 'bookasprofile'.
>
No. That is not what will happen. If we use the book as a profile, it 
will be our main source for deriving command sets for LFS builds. 
Personally, atm, I only see the need to support one syntax in our tool, 
but the fact that it is flexible and can do others, may be useful in 
some way in the future.  If we use the book as profile, there will 
*need* to be a way to add to, edit, adjust those command sets to 
personalize the build.  That will have to be part of the design.  The 
point of this thread was to show that with just a small amount of 
tweaking, it is possible to parse the LFS book, grab and store it's 
commmands for later use.  Once you have the commands and a structure for 
them stored in memory, there's no end to how you may be able to 
manipulate them/put them to use.  You should already be familiar with 
that kind of concept in nALFS, at least to a small degree.  After the 
nALFS profile is parsed, you still have the ability to choose which 
commands to run, and even, in a small way, edit the commands themselves.

So, parsing the LFS book as a profile is not a limiting thing, it is in 
fact very helpful, because we would then not have to maintain separate 
profiles just to be able to run the same commands that are already 
maintained in the book.  If you want to see the type of features that 
we're looking to implement, check out the wiki page:

wiki.linuxfromscratch.org/index.php?pagename=nALFS2Develpment

--
Jeremy Huntwork



More information about the alfs-discuss mailing list