to reproduce : - echo "--with-help=html" > autogen.input - make - touch (or even rm) helpcontent2/helpers/xmlhelp.dtd - make Actual : make -j 2 -rs -f /export/home/fpy/git/core/Makefile.gbuild build [ECH] CustomTarget/instsetoo_native/setup/setuprc [ECH] CustomTarget/instsetoo_native/setup/versionrc ... [LOC] top level modules: libreoffice [CUS] instsetoo_native/setup [PKG] instsetoo_native_setup [BIN] instsetoo_native [MOD] instsetoo_native [MOD] libreoffice [BIN] top level modules: libreoffice [ALL] top level modules: build-non-l10n-only build-l10n-only (real 0m50.070s) Expected : CustomTarget/helpcontent2 ... fails somewhere
This is working as designed. The DTD is not checked in the build. The xmllint DTD checking done on ~2500 files times ~70 languages will make the build very slow. Therefore the DTD checking is done at the gerrit level, once the patch is submitted. You get a "-1" if the patch does not comply with the DTD, and information on the offending file.
(In reply to Olivier Hallot from comment #1) ... > The xmllint DTD checking done on ~2500 files times ~70 languages will make > the build very slow. 1 run would be enough. for the record : % time find source/ -name '*.xhp' -exec xmllint --noout --dtdvalid helpers/xmlhelp.dtd {} \; real 0m13.888s user 0m2.743s sys 0m5.246s but would just need to check on couple of files. > Therefore the DTD checking is done at the gerrit level, once the patch is > submitted. this bugzilla is about the DTD itself. if you corrupt it, your local make won't complain, jenkins won't complain. it will only fail on the next .xhp change. should be 1 line somewhere like CustomTarget_html.mk. I suggest to REOPEN, and I'll fix it when I get more familiar with this .mk machinery, or someone already knowlegeable does it.
Comment from Cloph: It is not really a matter of time needed, at least not on linux - but Olivier is also correct in that the file is not used in a build/that checking all languages would be much slower (esp. on Windows). Also the file isn't really meant to be edited constantly. And people editing helpfiles also don't necessarily build LibreOffice themselves, so even if a build would use it, any error in the xhp files would still only be discovered by jenkins
In case of a build time check, xmllint would also then be a new dependency.
(In reply to Buovjaga from comment #4) thanx for the feedback. The build using xsltproc, I guess xmllint is not a huge gap. I suggest at least to have jenkins to check couple of XHPs when the dtd is changed Again, REOPEN doest not make it higher priority. just a reminder. Meanwhile, I'll try to consolidate that in wiki.
(In reply to fpy from comment #5) > (In reply to Buovjaga from comment #4) > > thanx for the feedback. > > The build using xsltproc, I guess xmllint is not a huge gap. > I suggest at least to have jenkins to check couple of XHPs when the dtd is > changed > > Again, REOPEN doest not make it higher priority. just a reminder. > Meanwhile, I'll try to consolidate that in wiki. As mentioned in comment 1, xmllint is run by the continuous integration for help patches.