arrangement of the XML sources

Alex Groenewoud alex at linuxfromscratch.org
Tue Jan 20 13:18:17 PST 2004


Matthew Burgess wrote:
> On Sun, 18 Jan 2004 22:35:44 +0100
> Alex Groenewoud <alex at linuxfromscratch.org> wrote:
> > The important thing is that everything about a package is in a single
> > file: if you want to bump the version of sed, remove a patch, and
> > tweak the instructions, there's only one file to edit, instead of two
> > or three different ones.
> 
> Yes, I see that now.  One thing to watch out for though is that
> installation instructions sometimes differ between chapters 5 and 6
> (e.g. patches specific to /tools, etc.).

That's why packages that are installed twice (or three times) have two 
(or three) different instruction sections.  These instruction sections 
are never identical, and it's easier to have two or three similar 
copies, than to figure out what is common and XInclude that.

> Now, on the assumption that we can get XInclude processing working
> on just parts of a file, where do we put the full contents of each
> package?

In a subdir: packages.  When editing the book it's simple to know where
to find a page in the sources: if it has an SBU at the top it's a
package and all the text is in packages/<name>.xml, if it hasn't an SBU
it's a glue section and the text is in chapterx.xml.  (This latter thing
would require much renaming when a chapter is added or removed, so I
would prefer symlinks for these -- see my last post on November 15, two
months ago.)

> Appendices A and B can be automatically
> generated I believe(they're just links) so don't require any source
> files at all.  Likewise, I think chapter 4 can be produced automatically
> as the download links are already in chapter 6.

Exactly, that's the idea: generate the lists and indexes.  These are
presentation things, to be moved out of the sources to the stylesheets.

> As far as the directory names are concerned, I still maintain that the
> current structure is the best we can do, simply because if I notice a
> problem in chapter 6 of the online book, the obvious place for me to
> look in the sources is in chapter 6.  No mental mapping required.

See above.  The mapping is simple: it's either a package, or it's not.

Alex




More information about the lfs-dev mailing list