[Swan-dev] always generating the man page

Andrew Cagney andrew.cagney at gmail.com
Thu May 7 21:42:26 EEST 2015

Several updates, and a question:

- I've added xmlto to the list of things installed in the test VMs

- I've started testing the below; be afraid

One annoying wart I've found is that some of the generated manpages get an
ipsec_ prefix removed only to then be put back.  During the build it does:
  xmlto version.5.xml -> ipsec_version.5
  mv ipsec_version.5 version.5
and then in the install it does:
  install version.5 .../man5/ipsec_version.5
(technically the last is $(MANPROCPREFIX)version.5).

Does anyone know of a good reason to not simply dump this behaviour; and
instead simply call man.xml files by their actual names?
For instance, version.5.xml would be renamed to ipsec_version.5.xml.  If
there really is a need to change ipsec_ to something else then that can be
handled during install.


On 7 April 2015 at 11:23, Andrew Cagney <andrew.cagney at gmail.com> wrote:

> Having hit yet another directory where there wasn't a generated man page,
> I'm going to change the build system to something like:
> make programs: only builds programs (i.e, no longer attempts to build man
> pages)
> make man: builds man pages
> make install-programs: only installs programs
> make install-man: only installs man pages
> make all: run programs and man
> and perhaps:
> make dist: runs "make man"
> and remove any generated man pages.  You'll notice that this lets us:
> - continue to build/test/install on the VMs (they should have xmlto but
> don't)
> Here's my spin on why:
> Long long ago, before there were public repositories, everyone passed
> source tar-balls around (and before that shell archives, and before that,
> ...).  To make things easier to build, the convention of including the
> generated documentation(1) and yacc(2) was adopted.  As projects moved to
> public repositories, the convention stuck; well for a short while. It
> didn't take long before projects realized that it was far simpler and more
> robust(3) to only have the original source code in the repo. If it was felt
> that distributing generated files was helpful then the "make dist" target
> can handle that.
> Andrew
> (1) for instance bundling generated postscript/pdf files; perhaps man
> pages were bundled because groff was hard to build or didn't exist :-)
> (2) try building bison without yacc or bison :-)
> (3) one key issue is date stamps, you really can't trust a repo to
> preserve the modification date of files - this is why our current build
> system has ended up with hacks to maybe run xmlto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20150507/2a644c42/attachment.html>

More information about the Swan-dev mailing list