I think I can say I've been officially horrified into a coma.
During a routine rebuild after installing DocBook tools, I wandered
away.. and then back and after half an hour, the build was still
stalled on the same command: xsltproc.
Huh? I thought, has it crashed?
Strace revealed that it was making a bazillion connections all over
the net. Loking at the XML, it's clear why. Because our
documentation relies on other XML includes that are URLs! I have to
depend on *sourceforge* being up to build Vorbis on my local box?
It is not acceptible for a default, out of the box build to require
being on the net to work.
It is not acceptible for it to rely on the Sourceforge admins being
sober for a change.
It is not acceptible for it to stay apparently dead for half an hour
for no reason the user can see.
It is especially not acceptible for it to *explode* after waiting dead
for half an hour when all I wanted was to build a library:
pdfxmltex --interaction nonstopmode spec.fo
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
(./spec.fo{/usr/share/texmf/pdftex/config/pdftex.cfg}
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german,
ngerman, n
ohyphenation, loaded.
xmltex version: 2002/06/25 v1.9 (Exp):
(/usr/share/texmf/tex/xmltex/config/xmltex.cfg)
No File: spec.cfg
! LaTeX Error: File `fotex.xmt' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: xmt)
Enter file name:
! Emergency stop.
<read *>
l.2 ...ustify" line-height="normal" language="en">
<fo:layout-master-set><fo:...
No pages of output.
Transcript written on spec.log.
make[2]: *** [Vorbis_I_spec.pdf] Error 1
make[2]: Leaving directory `/home/xiphmont/MotherfishCVS/vorbis/vorbis/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/xiphmont/MotherfishCVS/vorbis/vorbis/doc'
make: *** [all-recursive] Error 1
<p>We're dangerously close to the same kind of assrape imposed by
automake whenever a bug filters into that system: a middle layer
breaks for no reason that any user who isn't a developer of one of
those layers could be expected to understand. He can't fix it without
wasting hours of his own time. He does't know how to get around it.
The build just broke. "too freakin' bad".
I, personally, just want to correct a freakin' line of code. Instead
I'll be debugging other peoples' software tonight after wasting
another 50M of disk space on tools I otherwise couldn't care less
about.
...and while I'm at it, I'll be removing the doc build step from the
default build. If building documentation has become this fragile, it
*should not be part of the default libvorbis distro or build*. It may
be time to put it in its own CVS module, just to avoid pissing off
users and admins who don't give a shit about the elegance of XML or
all the cool things DocBook can do if you can debug it and are willing
to wait a really long time.
Fucking Fuck. Gar.
Monty
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
[In case it was not clear: I don't want DocBook eliminated. It is a perfectly acceptible choice for the authoritative original documentation. It does not belong in a library build, and takes the 'no generated files in CVS' dogma a bit too far. We need to move the DocBook out of the source code modules or make building them optional only and/or move them to another module and simply ship generated HTML witht he library source code modules.] Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> [In case it was not clear: I don't want DocBook eliminated. It is a > perfectly acceptible choice for the authoritative original > documentation. It does not belong in a library build, and takes the > 'no generated files in CVS' dogma a bit too far. > > We need to move the DocBook out of the source code modules or make > building them optional only and/or move them to another module and > simply ship generated HTML witht he library source code modules.]The problem here is that you don't have your stuff set up right. You don't need to make net connections if you have the proper catalog. As far as I know, Debian (unstable at least) has very reasonable defaults in all these areas, and I've not had any problems. That being said, I've had more than one fight with DocBook XML tools, but that's to be expected in some ways, at least until everyone gets the bugs out. You are correct about having them in a library build. It at least shouldn't be built by default, only on 'make doc' or something. This is part of the reason why I originally suggested moving docs out of the vorbis tree. I vote for a 'make doc' target and an reasonable expectation of tool support for people who will run 'make doc'. I don't believe that any links to sourceforge are required, but Ralph will no more about that. Minimally I think a person will need xsltproc or xalan, as well as the stylesheets for docbook. If you want PDF output, you'll also need a fop processor. jack. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Monty <xiphmont@xiph.org> said:> [In case it was not clear: I don't want DocBook eliminated. It is a > perfectly acceptible choice for the authoritative original > documentation. It does not belong in a library build, and takes the > 'no generated files in CVS' dogma a bit too far. > > We need to move the DocBook out of the source code modules or make > building them optional only and/or move them to another module and > simply ship generated HTML witht he library source code modules.] > > MontyMy choice here would be to leave them in the main source code module, but not build them by default (I did this to my local copy months ago, because I never had any desire to build the documentation every time I built the sources). Putting a copy of the generated source in cvs is something you could also optionally do - putting generated source in distribution tarballs is a definate requirement, of course. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.