BIRD 2.0.2 documentation build failure
Hello, I'm trying to build the documentation of BIRD 2.0.2 on Fedora and RHEL/ CentOS 7 which fails like this: --- snipp --- + /usr/bin/make -j4 -C doc make: Entering directory `/builddir/build/BUILD/bird-2.0.2/doc' make: Leaving directory `/builddir/build/BUILD/bird-2.0.2/doc' make: *** No rule to make target `/tools/progdoc', needed by `prog.sgml'. Stop. --- snapp --- When I decided to replace "$(srcdir)" in doc/Makefile by ".." it goes further, but still fails. Replacing "$(objdir)" by "../obj" and finally replacing "$(doc-srcdir)" by "." leads to the message that bird.sgml has a loop reference (which leads to an empty bird.sgml). And when removing this target, $(o)%.sgml: $(s)%.sgml $(objdir)/.dir-stamp cp $< $@ the documentation build even succeeds. In total that's then this diff: --- snipp --- --- bird-2.0.2/doc/Makefile 2018-01-16 10:46:06.000000000 +0100 +++ bird-2.0.2/doc/Makefile.doc 2018-11-25 16:38:22.988423717 +0100 @@ -1,7 +1,7 @@ # Force rebuilds .PHONY: progspell docs progdocs userdocs -doc-srcdir := $(shell cd $(s) && pwd) +doc-srcdir = . sgml2 := $(doc-srcdir)/sgml2 docs: progdocs userdocs @@ -16,11 +16,8 @@ userdocs: $(o)bird.html $(o)bird.pdf progspell: $(o)prog.spell -$(o)prog.sgml: $(srcdir)/tools/progdoc $(objdir)/.dir-stamp - $(srcdir)/tools/progdoc $(srcdir) $@ - -$(o)%.sgml: $(s)%.sgml $(objdir)/.dir-stamp - cp $< $@ +$(o)prog.sgml: ../tools/progdoc ../obj/.dir-stamp + ../tools/progdoc .. $@ $(o)%.html: $(o)%.sgml cd $(dir $@) && $(sgml2)html $(notdir $<) --- snapp --- Do you have any pointers? Is this a bug in BIRD or is this a Fedora/RHEL build system issue? Regards, Robert
On Tue, Nov 27, 2018 at 01:43:46AM +0100, Robert Scheck wrote:
Hello,
I'm trying to build the documentation of BIRD 2.0.2 on Fedora and RHEL/ CentOS 7 which fails like this:
--- snipp --- + /usr/bin/make -j4 -C doc
Hello Build of documentation is integrated in main build system, so you are not supposed to do 'make -C doc', but use make with appropriate target (e.g. progdocs) from BIRD root directory. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello Ondrej, On Tue, 27 Nov 2018, Ondrej Zajicek wrote:
Build of documentation is integrated in main build system, so you are not supposed to do 'make -C doc', but use make with appropriate target (e.g. progdocs) from BIRD root directory.
ah, there's my mistake. However, a regular "./configure && make" does not build any documentation but "make all docs" rather "make" does the job now, except that Fedora and RHEL/CentOS have their SGML files at another place compared to Debian. Unfortunately, make docs \ SGML_CATALOG_FILES=/usr/share/sgml/sgml-iso-entities-8879.1986/catalog does not work, because doc/sgml2{html,latex,txt} override this environment variable with "$DataDir/dtd/catalog", thus doc/LinuxDocTools.pm:245 has always the wrong value. Personally, I see two possible ways to address this using a patch, attaching both given that my freshly created GitLab account at gitlab.labs.nic.cz is limited (by default?) to zero forks/projects. Regards, Robert
On Tue, Nov 27, 2018 at 11:03:23PM +0100, Robert Scheck wrote:
Hello Ondrej,
On Tue, 27 Nov 2018, Ondrej Zajicek wrote:
Build of documentation is integrated in main build system, so you are not supposed to do 'make -C doc', but use make with appropriate target (e.g. progdocs) from BIRD root directory.
ah, there's my mistake. However, a regular "./configure && make" does not build any documentation but "make all docs" rather "make" does the job now,
Yes, there are separate targets for documentation (docs, userdocs, progdocs) as it requires obscure tools to build it and it is rarely necessary, so it is not built as part of the default 'all' target.
except that Fedora and RHEL/CentOS have their SGML files at another place compared to Debian. Unfortunately,
make docs \ SGML_CATALOG_FILES=/usr/share/sgml/sgml-iso-entities-8879.1986/catalog
Thanks for noticing the issue. Definitely, these tools should also accept the path from the environment if it is defined.
does not work, because doc/sgml2{html,latex,txt} override this environment variable with "$DataDir/dtd/catalog", thus doc/LinuxDocTools.pm:245 has always the wrong value. Personally, I see two possible ways to address this using a patch, attaching both given that my freshly created GitLab account at gitlab.labs.nic.cz is limited (by default?) to zero forks/projects.
We generally prefer patches through mailing list. Seems to me that both patches makes sense. Thanks. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
diff --git a/doc/LinuxDocTools.pm b/doc/LinuxDocTools.pm index 39bb401..d73fc75 100644 --- a/doc/LinuxDocTools.pm +++ b/doc/LinuxDocTools.pm @@ -242,6 +242,7 @@ sub process_options # removes iso-entites sub directory after doing make install.) # $ENV{SGML_CATALOG_FILES} .= (defined $ENV{SGML_CATALOG_FILES} ? ":" : "") . + "$main::prefix/share/sgml/sgml-iso-entities-8879.1986/catalog:"; "$main::prefix/share/sgml/entities/sgml-iso-entities-8879.1986/catalog"; $ENV{SGML_CATALOG_FILES} .= ":$main::DataDir/linuxdoc-tools.catalog"; $ENV{SGML_CATALOG_FILES} .= ":$main::/etc/sgml.catalog";
Hi I guess this is a typo and it should be: - "$main::prefix/share/sgml/sgml-iso-entities-8879.1986/catalog:"; + "$main::prefix/share/sgml/sgml-iso-entities-8879.1986/catalog:" . to include both paths? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tue, 11 Dec 2018, Ondrej Zajicek wrote:
I guess this is a typo and it should be:
- "$main::prefix/share/sgml/sgml-iso-entities-8879.1986/catalog:"; + "$main::prefix/share/sgml/sgml-iso-entities-8879.1986/catalog:" .
to include both paths?
yes, unfortunately it's a typo. I'm sorry. Regards, Robert
participants (2)
-
Ondrej Zajicek -
Robert Scheck