From: Baptiste Daroussin <bapt@FreeBSD.org>
Subject: Re: Allow gzipped .so and search .so in manpath
Date: Wed, 26 Nov 2014 21:24:13 +0100 [thread overview]
Message-ID: <20141126202413.GF82931@ivaldir.etoilebsd.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
On Wed, Nov 26, 2014 at 09:10:33PM +0100, Ingo Schwarze wrote:
> Hi Baptiste,
> Baptiste Daroussin wrote on Mon, Nov 24, 2014 at 03:36:29PM +0100:
> > Here is a new patch that allows to open gzipped .so files
> > as well as looking inside mpath for the files requested.
> This is a terrible layering violation for three (!) reasons:
> 1. The mandoc toolbox consists of code in two major categories:
> a) code that is handling files irrespective of context
> b) code that is aware of file context / file systems
> While b) code is allowed to use a) code, the reverse
> is not true.
> The file read.c is part of the file handling code a), while
> manpath.h is part of the b) interface; so read.c cannot
> include manpath.h.
> It is true that the implementation of .so in roff.c (which
> is also part of a) slightly strains the "irrespective of
> context" paradigm by accessing another file. But at least
> it retrieves the file in exactly one well-defined place
> near the original file, and this strain is unavoidable
> if we want to support .so at all.
> Widening the gap by making read.c search for files along
> the path is neither acceptable nor needed.
> 2. As proposed, the patch is horribly inefficient.
> For some purposes, the function mparse_readfd() is called
> in inner loops, so it is not acceptable to do such expensive
> operations in there.
> Explained differently, we must not recalculate the manpath
> for each and every file we parse. Think about makewhatis(8),
> for example.
> Calculating the manpath belongs on the level of the main
> program, not into some inner loop in a library.
> 3. The patch utterly breaks the library hierarchy.
> The function mparse_readfd() is a libmandoc interface
> as documented in mandoc(3), while manpath.h is not.
> While manpath.c can (and does) use libmandoc, the reverse
> cannot happen.
> You see part of the havoc wrought in that you suddenly
> need manpath.o to link demandoc(1) even though that
> program does not use the manpath.h interface.
> I have to think about a better way to solve this.
> Maybe i should make mparse_readfd() use mparse_open()
> and extend mparse_open a bit to use file.gz if file
> is not found. Or something like that.
> It shouldn't take too long to figure out.
I was expecting the above :)
What about using zlib directly, that could simplify a bunch of things.
> > This allows zshall manpage which contains: .so man1/zshmodules.1
> > to work with mandoc, tested on freebsd this .so find as expected
> > /usr/local/man/man1/zshmodules.1.gz
> The .so links are a bad idea in the first place, so it would be
> good to get rid of them completely. But admittedly, that's a
> separate matter.
Right now in the ports tree I'm ripping them at package creation using soelim
from groff and I wrote minimalistic version in base to be able to continue using
that when groff will be removed.
[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2014-11-26 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 14:36 Baptiste Daroussin
2014-11-26 20:10 ` Ingo Schwarze
2014-11-26 20:24 ` Baptiste Daroussin [this message]
2014-11-27 0:12 ` Ingo Schwarze
2014-11-27 2:03 ` Ingo Schwarze
2014-11-29 17:54 ` Baptiste Daroussin
2014-11-29 18:14 ` Ingo Schwarze
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).