[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.
Andrew
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