Parsing the LFS book as a profile
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
> 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:
More information about the alfs-discuss