Build doesn't include cspec documentation for Decompiler

[SamB]

This is essentially #1856 by another name. To remind you, the problem there was:

Describe the bug cspec documentation files exist in Ghidra/Features/Decompiler/src/main/doc/ yet are not built alongside its siblings in the build.gradle script for the Decompiler

Expected behavior The docs are built. Looks like they may have just been left out of the buildDecompilerDocumentationPdfs and buildDecompilerDocumentationHtml tasks

Environment (please complete the following information):

• OS: Windows
• Java Version: 11.0.7
• Ghidra Version: 9.1.2

Additional context #472

It seems to me as though #1856 got closed in error due to the comments discussing more ambitious goals (documenting pspec, which would actually require someone to write docs).

I'm hoping that if you reopen #1856, somebody will actually take a look at my PR #3137 (adding cspec to the build in a way that should be minimally invasive). (Alternatively, I could presumably edit the summary to say that it fixes this issue instead of that one.)

[mumbel]

I think the issue remains, is this process to build these docs cross platform or just Linux? Does 3137 build on windows/osx? (which was the reasoning/hesitation stated by the devs in the other issue + PR you're talking about, 2108)

[SamB]

@mumbel The decompiler help/documentation build tasks weren't set up to build on Windows before (probably because it would be such a pain to set up the toolchain to run docbook-xsl). In fact, when I started, the installation path /usr/share/sgml/docbook/xsl-stylesheets/ was hardcoded in many places, but doesn't even work on my Debian install, so I replaced that installation path with http://docbook.sourceforge.net/release/xsl/current. (I also added --nonet to the xsltproc commandline to make sure that we actually use the locally-installed copy; thanks to the magic of XML catalogs, that actually works.)

So obviously those build tasks aren't part of the standard build; instead, when the documents are updated, someone has to manually run the relevant tasks and commit the output files.

Where PR #2108 went wrong was trying to pull these tasks into the default build, which naturally caused issues on systems without xsltproc and docbook-xsl installed, or even if docbook-xsl was installed, but couldn't be found specifically at /usr/share/sgml/docbook/xsl-stylesheets/. Not sure why that hadn't occurred to the PR's author. Temporarily forgot Windows existed, maybe?

Anyway, I also tested that my PR doesn't break the build on Windows: my source tree was on Windows to start with, and I was just running the doc build on my WSL2 Debian, in that same source tree. (Having poked around Debian's SGML/XML infrastructure in the past, I knew that it worked, and that it involved a lot of cooperation between packages to get everything to work ... probably not a good candidate for attempting to install on Windows.)