Sunday, January 25, 2009

Cutting and pasting without looking

One of the goals is to create a setup that can be used to build the system (or parts of the system) without excessive operator intervention and time. The builder is still obligated to ensure that the setup conforms to the LFS/BLFS BOOK and is consistent with the desired results before executing the setup.

In creating the setup, I have been wishing to reduce the amount of cutting and pasting since that in itself is a tedious and error-prone process.

The instructions in the LFS and BLFS books are maintained as a set of XML files.

svn ls svn://svn.linuxfromscratch.org/LFS/tags/
svn ls svn://svn.linuxfromscratch.org/BLFS/tags/

Subdirectories of tags contain various versions.
Sometimes you have to navigate to deeper subdirectories until you see the subdirectory "BOOK" in a subdirectory of the version you want (a little confusing).

LFS-6.3 which I am very strongly considering dropping back to is in
svn ls svn://svn.linuxfromscratch.org/LFS/tags/6.3/BOOK

For BLFS-6.3, the appropriate XML files are in
svn ls svn://svn.linuxfromscratch.org/BLFS/tags/6.3/6.3/BOOK

I put them in /BOOK/BLFS-BOOK-6.3-XML with the command
svn co svn://svn.linuxfromscratch.org/BLFS\
/tags/6.3/6.3/BOOK /BOOK/BLFS-BOOK-6.3-XML

In the BLFS-BOOK-6.3-XML directory is a Makefile that has capabilities for various renderings of the XML files including "make dump-commands". Also there is a stylesheets subdirectory from which I may some day learn to get a handle on XSL stylesheets for xsltproc.

In the meanwhile, I resorted to some things that seem more down to earth. My first attempts were with sed, but I couldn't get sed close to do what I wanted.

So I turned to the higher powered perl.
Somehow, a work-in-progress script evolved with the name t-pl.
t-pl digs up useful information including package name, version, url, md5, patches, and commands and prints it out in the format like the custom-tools scripts.

t-pl requires at least the name of one of the xml files.
It will allow the name to contain a sort of wildcard specification of .* which means zero or more of anything. If there is more than one xml file that matches the "name", then it lists out the names of the files that match.

For example, t-pl gtk.* will list out:
./x/lib/gtk+.xml
./x/lib/gtk+2.xml
./xincludes/gtk-doc-rebuild.xml
./gnome/otherlibs/gtkhtml1.xml
./gnome/add/gtksourceview.xml
./gnome/add/gtkhtml.xml
./gnome/core/gtk-engines.xml
./general/genutils/gtk-doc.xml

Then if I want to see the info for gtk2, I can do:
t-pl gtk+2

The list out feature is especially useful in the LFS BOOK XML because more than one chapter often contains an XML file of the same name.
If I am in /BOOK/LFS-BOOK-6.3-XML, then t-pl grub will list:
./chapter08/grub.xml
./chapter06/grub.xml

t-pl allows a directory prefix to the name, so for the chapter06 grub info:
t-pl chapter06/grub

If you provide the .xml extension on the name it works also.

To output just the commands, there is a switch --plain.

To output the entities, there is a switch --dump-entities.
The --dump-entites is for debugging t-pl and for learning about some of the subtitutions that go on in making sense of these XML files.

I can use the output from t-pl to put in /jhalfs/custom/tools and use the remake_custom.sh and make_cusom.sh to build the package. Or, I could use that shoo, or the package_builder script to do it. This is getting closer to what I have been wanting. Since these things are evolving and improving I should probably, in the near future, bring them all together again with the latest improvements and review ans summarize how they can work together.

NOTE:
It was a challenge to get t-pl uploaded to google docs so that it would display correctly since it contains many things that are html special characters. It can also be a challenge to get it copied locally in the form it is intended to be. Google docs is used because I don't have another way to present documents at present.

Here is how I save a copy of the document locally:

METHOD 1

Open an xterm window

Start vi to edit a new file:
vi t-pl

It should be an empty file.
Start Insert mode by typing a lowercase i

Navigate to the document in a browser (firefox)
When the document is displayed,
Right-click the mouse
Click Select All

Bring the xterm window into focus.
Get the mouse over the vi window
Click the middle button of the mouse
Hit the ESC key
Position to the end of the document by typing $G
Use the up-arrow key to position to the first blank line that preceeds the "Edit this page ... Google Docs" stuff
Delete the ending garbage by typing :.,$d and press <ENTER>
Hit the ESC key
The ending "Edit this page ... Google Docs" should be removed.
Save the file with :x and press <ENTER>
The last 4 lines of the file should look like this:
if ($plain != 1) {
print qq@xEOFx\n@;
print qq@) > tmp\n@;
}

METHOD 2

Save to a file with lynx
Determine the hyperlink_address, e.g.,
http://docs.google.com/Doc?id=dg7ck9hb_118hdjr63gn

lynx -dump -nolist -dont_wrap_pre hyperling_address > t-pl
e.g.,
lynx -dump -nolist -dont_wrap_pre \
http://docs.google.com/Doc?id=dg7ck9hb_118hdjr63gn \
> t-pl

Remove the "edit this page ... Google Docs" garbage
vi t-pl
Position to the end of the document by typing $G
Use the up-arrow key to position to the first blank line that preceeds the "Edit this page ... Google Docs" stuff
:.,$d and press <ENTER>
:x and press <ENTER>

The lynx method will leave a few extra spaces at the end of some lines, but it may still work.

Sorry that I don't have a better way to present documents than Google Docs. I can't put it directly in Blogger because there it really gets trashed.


FOOTNOTE:
I got a little annoyed when I tried to install subversion on my newest system so that I could test the above svn commands. The version of subversion in BLFS-6.3 requires the installation of subversion dependencies and finding the one with a version that matches the subversion version is a challenge. But I decided that I'll just install an older version of subversion that is in BLFS-6.2.0 which can still be found in the BLFS Museum which doesn't require all that extra stuff that I don't need for what I am using it for.

Remember I said the builder is still obligated to ensure that the setup is consistent with the desired results and this is very evident in subversion. The build instructions contain many optional instructions for javahl things and swig things and I cut all of that stuff out of my installation.

One of the beauties of linux from scratch is that you can install the software that works for you without having to also install a whole bunch of stuff that you don't know what it is or whether you want it. If this means installing an older version that didn't require you to install all that stuff that you didn't know why you would ever want it, then you can.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

Click blog title for the latest post