Hi list
I've been thinking about this "parsing commands from the books" problem for
awhile and read some discussions here. I haven't reviewed Makefiles generated
by jhalfs, but I feel that the currently used parsing method has a problem:
We need to decide what commands to accept from the books for execution. In LFS
book we don't have many commands that should not be executed (except for those
in Making the LFS system bootable -section). In BLFS, however, we have many
such commands, for example commands in sections "Additional X Window System
Configuration" and "X Window System Components" should never be executed
automatically. But as far as I understand, these commands are also enclosed in
<userinput>...</userinput> tags in the book sources. I don't like the idea
that all of these exceptions (which are very numerous in BLFS) should get
special handling in the parser. Not even talking about conditional execution,
like: "If you have [A] or [B] installed, execute {AA}, otherwise execute
{BB}."
I feel that some metainformation should be added to the book sources
themselves, for example in the form of specially formatted comments, if XML
DocBook is not flexible enough. These comments would not be a big maintainance
problem for the book editors, but would be a great help for alfs developers.
It may be argued that there are many LFS editors who will most like dislike my
idea and that alfsers are minority in LFS builders, but I ask how big the
minority will become when we have a full-fledged build tool ready made.
But back the the idea of metainformation:
In addition of telling the the alfs parser that the following commands from
the book should be executed, these metainformation comments (or whatever)
could give some more details to the parser, for example the conditions
under which it should be executed. Also information such as the following
commands apply patches could be provided. This information could then be
displayed to the user who is building a system (or editing generated
profiles).
Another issue that has been in my mind and which has not yet been resolved is
the output format that will be generated by the command parser. For jhalfs
this is makefile-format, but obviously this is not sufficient for a full
building environment. nALFS uses XML profiles, but these are not
easy to edit. To me this seems as a very important concept, since:
1. LFS is not a ready-made distribution and almost every LFS user makes many
adjustments to the way their systems are being built.
2. It should be quite easy for the alfs tool to read generated profiles and
execute commands based on that. alfs should not have intimate knowledge of
features and command-line options of various Unix utilities (has nALFS
has to), but rather should just pass the commands to an
interpreter which can tell if they completed sucessfully. In the most
extreme cases, the builder should be able to replace bash with tcsh and
with proper editing of profiles should be able to build a system with
his/her preferred shell.
Again I feel that a new format should be introduced, which would be easy to
parse by alfs and especially easy to read, write and edit by humans. simple
Shell scripts are not enough since then the alfs daemon cannot tell which of
the commands in the script failed, if shell just exits with error code 1.
I also think that some variable references must be present in the
generated profiles to make it more easy to build different versions of
packages than those that the books use. For example in BLFS many packages'
documentation is installed to package and version specific directories under
/usr/share/doc. If the package version is changed by the builder, only one
command should need modification (eg. VERSION=...) instead of modifying all
those mkdir and install commands.
I would like to here some comments regarding my views of the future of alfs
and the books. I believe that it would greatly help alfs development, if the
book itself would blend towards alfs, without abandoning its important goals.
The most of LFSers would probably be interested in automated building
of their systems and therefore ^.*LFS.*$ should co-operate.
--
Tapio
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
