From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o946ZRJx002236 for ; Mon, 4 Oct 2010 02:35:27 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 2058B157917 for ; Mon, 4 Oct 2010 08:35:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id ToCxBpglM6F6 for ; Mon, 4 Oct 2010 08:35:19 +0200 (CEST) X-KTH-Auth: kristaps [85.8.61.46] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: tech@mdocml.bsd.lv Received: from lappy.cust.alltele.se (h85-8-61-46.dynamic.se.alltele.net [85.8.61.46]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3D891157916 for ; Mon, 4 Oct 2010 08:35:17 +0200 (CEST) Message-ID: <4CA975A5.1080104@bsd.lv> Date: Mon, 04 Oct 2010 08:35:17 +0200 From: Kristaps Dzonsons User-Agent: Thunderbird 2.0.0.23 (X11/20100318) X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv Subject: Re: mdocml: Unify mdoc and man enums and structs into mandoc.h. References: <201010021014.o92AEcOr023027@krisdoz.my.domain> <20101002175621.GB19515@iris.usta.de> <4CA8B41C.7020300@bsd.lv> <20101003223647.GA20734@iris.usta.de> In-Reply-To: <20101003223647.GA20734@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Many, and conflicting ones; so i cannot present final solutions, > but some thoughts indeed. Ingo, yeah, by the large I agree---for the time being I'll revert the changes. > Regarding libmandoc.a, sure. Actually, i don't see much of a point > in having libraries at all in this context; i doubt that anybody will > ever want to use the parsers outside the mandoc program, or, put > the other way round, all functionality that can reasonably be based > on the mdoc language can probably reasonably be included into the > mandoc binary program. > > Regarding makewhatis, apropos and man.cgi, i do not have much hope. > Remember that those must be able to work on the -Tascii output, > at least in OpenBSD, because that's the only version of the manuals > getting installed, and there is next to no hope to have that changed, > based on what Theo and Bob say. Besides, i don't really see a need > to install manual source code either. On a typical production > system, you don't need manual source code, just as you don't need > program source code; besides, the src.tar.gz ball is readily > available for each release, and anonymous CVS is not rocket science > either, in case you need the sources for some reason. I agree, but this is not relevant: if OpenBSD doesn't want to use the libraries, the object files can be linked directly into mandoc. > Regarding mandoc.h, actually, i still don't see the point. > Why should a file like mdoc_macro.c, or even mdoc_term.c, > be forced to include man data structures and function prototypes? > In the current implementation, there is not a single file > including both man.h and mdoc.h or both libman.h and libmdoc.h, > except main.c and tree.c. And even if there were one or two > such files: What is the advantage of a frontend file including > just mandoc.h instead of man.h and mdoc.h? Yep, this is the reason for my patch reversion. Pushing libmdoc, libman, and libroff tighter together can occur without header merging of the {man,mdoc,roff}.h headers. Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv