[Sorry Karl, I'm cc:ing you often these days. The discussion is about introducing a `make html' target to Automake. This would only build the texi documentation -- nothing installed.]
>>> "Richard" == Richard Dawe <[EMAIL PROTECTED]> writes: [...] >> The problem, with html, is that nobody agree about what the >> ouput should be. I'd say that if we support html, we should >> use the default makeinfo output (which is to split on nodes), >> and let the user say `AM_MAKEINFOFLAGS = --no-split' when wanted. >> This is what we do for info files already. Richard> OK. But then it gets hard to know which files to Richard> remove. Removing *.html seems a bit dangerous to Richard> me. AFAICT `makeinfo --html --no-split' creates file named `mumble.html', while `makeinfo --html' creates a directory named `mumble.html/'. So it seems we could handle both cases with `rm -rf mumble.html'. Richard> Perhaps some support script could produce a list of Richard> nodes, so that we know remove the right HTML Richard> files. What should it be called? texinodes? Apparently we won't need this for `makeinfo', still this is a regular issue when writing `clean' rules for Makefiles. Ideally, each tool that produces many files should provide a command to cleanup these files. Otherwise the Makefile author (here, Automake) has to hard-code many tool-specific knowledge that is unlikely to survive evolutions. >> Still some people prefer using texi2dvi, and some also want to >> distribute html files. It seems hard to satisfy these. Richard> Do you mean texi2html, rather than texi2dvi? Yes, sorry. Richard> I think using makeinfo should be the default. I concur. Richard> Then how about supporting an option in Richard> AUTOMAKE_OPTIONS, to use texi2html instead: Richard> html-texi2html? I'm not sure this is worth an option. Maybe we can arrange the rules so that replacing makeinfo by something else is easier. For instance using a $(MAKEINFO_html) variable as the command, something similar for the options. When using another tool, I'd let the user clean the resulting files itself (or s/he can arrange to use texi2html -subdir=mumble.html, so that the output looks the same as far as clean rules are concerned). For the worst cases (package building html documentation from info files with random tools) your patch provides recursion over the `html' targets, and user can override the `html-am' target (or whatever they are called) with custom rules. That still looks like a win over existing setups. [...] -- Alexandre Duret-Lutz
