>>- Doing a new build needs to rebuild the whole manual, regardless >> of the number of pages changed (10 is a drop in the ocean if >> you consider the thousands of pages in the manual) > > Well, I thought there was some possibility like the > $ xsltproc --stringparam rootid "<ID>" xsl/html.xsl manual.xml > mentioned in the dochowto.
This is not possible, as one change in a file can in turn change much more output files (think indexes, table of contents in page sidebars, <xref/> cross references, etc). The rootid hack is only relevant for testing purposes, when an overall broken manual is not really a problem. >>- Last but not least this works this way, because unfortunately >> those who complain about this system rarely end up >> improving/fixing/submitting bugs and patches against >> livedocs, so that we can get out of this situation. > > I see, so it all boils down on getting livedocs to production quality, > so the whole process of supplying the manual can be redone, do I get > this right? Yes, noone puts effort into improving our build situation as there is a great prospect on the horizon to replace the whole system. There is no point in improving a system which is on the way out. In fact that energy should be directed at the new shiny system under development. Goba
