Coming to what is needed for automating the book (I do not mean automating the building of a system, but rather being able to automate testing), one thing which is really hard to deal with is the fact that there are several (sometimes incompatible) options on the same footing in the instructions.
For example, subversion. Along with the needed instructions, there are instructions for swig and javahl, which (a) rely on some optional packages to be installed, one even not in the book (swig) (b) could appear to be less important to get an operational executable. For an automated tool, there is no way to differentiate those. So it stops because the needed dependencies have not been installed. Another example is the 'which' page, which contains two different builds: one of those builds is not even associated to a package, something a human sees immediately, but that is hard to see for an automated tool. I could cite dozens of examples. Another one: the instructions for linking directories and files if X is installed in a non standard place. Those instructions are not needed and return an error if X is installed in /usr. What I would suggest is that all the instructions, which are associated to something optional, should be with an attribute role="nodump". I understand that would imply a heavy editing, and that you might not be fond of doing it. OTOH, if that is not done, jhalfs (and I think any other automating tool) will always need a human to check and edit the generated scripts. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
