<div dir="ltr"><div><div><div><div><div><div>Having hit yet another directory where there wasn&#39;t a generated man page, I&#39;m going to change the build system to something like:<br><br></div>make programs: only builds programs (i.e, no longer attempts to build man pages)<br></div>make man: builds man pages<br></div>make install-programs: only installs programs<br></div>make install-man: only installs man pages<br></div><div>make all: run programs and man<br><br></div><div>and perhaps:<br><br></div><div>make dist: runs &quot;make man&quot;<br></div><div><br></div>and remove any generated man pages.  You&#39;ll notice that this lets us:<br><br></div><div>- continue to build/test/install on the VMs (they should have xmlto but don&#39;t)<br></div><div><br></div><div>Here&#39;s my spin on why:<br><br>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&#39;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 &quot;make dist&quot; target can handle that.<br><br></div><div>Andrew<br><br></div><div>(1) for instance bundling generated postscript/pdf files; perhaps man pages were bundled because groff was hard to build or didn&#39;t exist :-)<br></div><div>(2) try building bison without yacc or bison :-)<br></div><div>(3) one key issue is date stamps, you really can&#39;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<br></div></div>