build: hard-fail configure if asciidoctor is missing

[grandixximo]

Summary

Fixes #4084.

docs/src/Submakefile builds manpages for halcompile components (5axisgui.1 etc.) via asciidoctor, regardless of --enable-build-documentation. The configure probe added by #4053 was nested inside if BUILD_DOCS = yes, so ./configure --enable-run-in-place (no docs opt-in) silently passed and make later crashed with asciidoctor: command not found.

Changes:

• src/configure.ac: probe moved out of the BUILD_DOCS gate; missing asciidoctor is now AC_MSG_ERROR with apt / dnf / gem install hints. PDF / HTML / Rouge probes stay gated.
• debian/control.top.in: drop <!nodoc> from asciidoctor (per @BsAtHome; even nodoc builds need it).
• debian/configure: remove now-duplicate asciidoctor from the head of DOC_DEPENDS.

Test plan

• ./configure --enable-run-in-place with asciidoctor present: succeeds; make ../docs/man/man1/5axisgui.1 builds.
• After apt remove asciidoctor: configure aborts with no asciidoctor, manpages cannot be built + install hint, instead of failing inside make.
• ./configure --enable-run-in-place --enable-build-documentation=html + make builds full English HTML (585 pages, 453 manpage HTMLs, link checker clean).
• Indentation of untouched lines preserved (blame intact on the GS / RSVG / Rouge probe blocks).

[BsAtHome]

In debian/control.top.in you have:

    asciidoctor <!nodoc>,

Shouldn't you also remove the nodoc tag because halcompile needs it?

[grandixximo]

Thanks, pushed an amend (0c24fb2f02):

• dropped <!nodoc> from asciidoctor in debian/control.top.in
• removed the now-duplicate asciidoctor entry at the head of DOC_DEPENDS in debian/configure
• tightened the configure.ac comment to one line

Re-ran the configure probe with / without asciidoctor and a full --enable-build-documentation=html build (585 HTML pages, 453 manpage HTMLs, link checker clean). groff-base, imagemagick, libunicode-linebreak-perl, po4a kept their <!nodoc> tags since the asciidoctor manpage pipeline doesn't reach them.

Tangentially: make htmldocs / pdfdocs / docs work standalone after one full make (halcompile component pages come from objects/man/*.adoc, built by halcompile during the C build, so a fresh-tree docs-only build silently omits them). Worth wiring a docs-with-components target that depends on halcompile manpages first, and maybe promoting that to the default for docs-only flows? Happy to draft a follow-up if you want it.

[BsAtHome]

Tangentially: make htmldocs / pdfdocs / docs work standalone after one full make (halcompile component pages come from objects/man/*.adoc, built by halcompile during the C build, so a fresh-tree docs-only build silently omits them). Worth wiring a docs-with-components target that depends on halcompile manpages first, and maybe promoting that to the default for docs-only flows? Happy to draft a follow-up if you want it.

Yes, that needs to be fixed too. The manpages target must run halcompile to extract the docs. However, the current setup was only necessary because the PDFs built the manpage collection from the troff sources instead of the adoc sources. This is no longer true and the current hack is no longer necessary. Halcompile still needs to be able to run asciidoctor because it can generate troff manpages directly (as compatibility measure).

Now you can run halcompile --adoc to extract only the component's manpage in adoc format from the component. Then you use a second rule to build troff from adoc manpages and thereby simplify the build. Take a look at the hal/components/Submakefile on the rules for COMP_MANPAGES and COMP_DRIVER_MANPAGES.