On Thu, Jul 07, 2022 at 03:42:27PM +0200, Ingo Schwarze wrote:
> Hi Daniel,
> 
> Daniel Dickman wrote on Thu, Jul 07, 2022 at 12:03:18AM -0400:
> 
> > Over a decade ago there was some work in bsd.man.mk to build tbl pages 
> > with mandoc. For example this commit from 2010:
> > 
> > ----------------------------
> > revision 1.32
> > date: 2010/10/17 22:47:08;  author: schwarze;  state: Exp;  lines: +8 -18;
> > Build tbl(1) pages with mandoc(1), not groff.
> > Xenocara build checked myself, base build also by jmc@, thanks!
> > "don't wait for me" deraadt@
> > 
> > Pages in base using tbl mostly look good already except for the
> > rare .T{ macros; there may still be a few formatting issues
> > in xenocara, please speak up when you run into them.
> > Eventually, mandoc will catch up.
> 
> Today, the tbl(7) formatting of all the pages you are touching
> is byte-by-byte identical between groff(1) and mandoc(1) -
> with one minor exception in infocmp(1) where groff(1) renders
> a few horizontal lines incorrectly due to a bug in groff(1).
> 
> > ----------------------------
> > 
> > Back then there was some special infrastructure to build these man pages 
> > if they were named something like *.6tbl.
> > 
> > That convention is a local OpenBSD convention, it does not exist outside 
> > of our tree.
> > 
> > At this point the special naming for these man pages is no longer needed:
> 
> That is completely correct.
> 
> > * games/phantasia/phantasia.6tbl
> > * gnu/usr.sbin/mkhybrid/src/mkhybrid.8tbl
> > * share/man/man4/man4.hppa/cpu.4tbl
> > * share/man/man4/wi.4tbl
> > * share/man/man4/man4.hppa/cpu.4tbl
> > * usr.bin/infocmp/infocmp.1tbl
> > * usr.bin/tic/captoinfo.1tbl
> > 
> > The benefits are:
> > - The affected Makefiles are shortened by 3+ lines
> > - diffing external software like mkhybrid against the original sources 
> >   results in less noise
> > - remove an unnecessary cp step doing the build
> 
> The price to pay is relatively minor: making it slightly harder to
> inspect commit history of these manual pages.  But these are not
> edited often anyway, so that's not a big deal.
> 
> > ok on the diff below? (I've left out the man page renames from the diff 
> > for brevity)
> 
> I don't have a strong opinion either way.  If you think it's worth it,
> i do not object.
> 
> From visual inspection, the diff looks correct to me.  I also tested
> building and installing in the affected directories and noticed no
> issues.  I did not run a complete make build / make release cycle
> though, but i trust you to not break that.
> 
> Yours,
>   Ingo
> 
> 

for me it's a good move:

- easier to find(1) our pages within the source tree
- there are so few of them it just looks inconsistent
- simpler

but i hate losing easy access to cvs history too. so i also have no
strong opinions.

jmc

Reply via email to