Re: Standard docbook Makefile.am recipe

[John Kodis <kodis gsfc nasa gov>]

On Thu, Dec 28, 2000 at 09:47:01AM -0700, John Fleck wrote:
> On Wed, Dec 27, 2000 at 10:40:37AM -0500, John Kodis wrote:
> > Is there a recommended Makefile.am "recipe" for generating .html from
> > docbook .sgml files?  The techniques that I've found in use either
> > require several lines of Makefile.am text for each html file that gets
> > generated, or they fire up multiple db2html instances when run under
> > "make -j".  
> 
> The closest thing to a standard recipe is in the gnome-hello program
> in gnome cvs: gnome-hello/doc/C/Makefile.am

Yes, I should have thought to look to the gnome-hello module for
enlightenment.  Unfortunately, the approach take in gnome-hello
doesn't scale well.  Once the help file gets large enough to require
multiple sect1 sections, hence generating multiple .html files, the
two html-generating rules:

    gnome-hello.html: gnome-hello/gnome-hello.html
	    -cp gnome-hello/gnome-hello.html .

    gnome-hello/gnome-hello.html: $(SGML_FILES)
	    -db2html gnome-hello.sgml

have to be duplicated for each section.  In addition to being tedious,
this doesn't work when run with "make -j".  Make fails to see that the
db2html rules are all identical, and so trys to run them all in
parallel.  This causes the output files to all step over each other.

I've been able to solve both of these scaling issues by using the
docbook.css files as a timestamp of when db2html was run.  This
requires only a single list of all the .html files as the initial
target, and works correctly under "make -j".

    $(HTML_FILES):          $(DB_DIR)/docbook.css
	    -cp $(DB_DIR)/$@ .

    $(DB_DIR)/docbook.css:  $(SGML_FILES)
	    -db2html $<

The problem with this approach is that if any of the $(DB_DIR)/*.html
files get deleted, make never notices since the .html files are
dependant only on the docbook.css file -- not on the html files in the
directory that db2html creates.  

I'm not completely satisfied with either of these two solutions, but
haven't been able to come up with anything better.

-- 
John Kodis <kodis acm org>
Phone: 301-286-7376