discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Peter Bray <pdb_ml@yahoo.com.au>
Cc: discuss@mdocml.bsd.lv
Subject: Re: mdocml [CVS_2015_11_07] Installation Paths
Date: Sat, 7 Nov 2015 14:34:39 +0100	[thread overview]
Message-ID: <20151107133439.GC10393@athene.usta.de> (raw)
In-Reply-To: <563D956E.4010202@yahoo.com.au>

Hi Peter,

Peter Bray wrote on Sat, Nov 07, 2015 at 05:08:46PM +1100:

> Another couple of questions, yes I know, there have been a few already ;-)

Thanks for looking at mandoc so thoroughly!

> I'm have been investigating manual page systems, and with multiple
> systems on the same hosts, I didn't want any conflicts.
> 
> So I added to 'configure.local', some new variables: PROGRAM_PREFIX
> and PROGRAM_SUFFIX, and defined the BINM_* and MANM_* variables in
> terms of these variables. See the configure.local at the end of this
> email.

No problem doing that locally if you want to.
Though personally, i find individual lines like

  BINM_APROPOS=mandoc_apropos

much easier to read, but that's maybe a matter of taste.

> Question: Could such behavior be the default?
> By this I mean the use of the variables like PROGRAM_PREFIX

No, i'd rather have people consider each program and manual
separately.  Renaming stuff is unwise unless you really
consider the implications for each single file.

> and PROGRAM_SUFFIX

I don't see any use for that.  Even you don't seem to use it.
In general, i dislike scaffolding and want to keep stuff simple.
Just because something can be done doesn't mean it should.

> in the default
> computations in 'configure', but with 'configure.local', still
> allowing other users to make personal overrides. Of course, both
> variables should default to the empty string. Just asking :-)

And then we need to talk about precedence and overriding in the
documentation, and people get confused?  No, i don't like that.

> On installation with the above in use, I noticed that soelim(1) is
> installed without a requested prefix (and suffix) from BINM_SOELIM
> (see the output of the find command below). The same is true of the
> soelim manual page. And although 'config.h' defines 'BINM_SOELIM'
> correctly (based on configure.local), nothing uses this definition.
> It is even documented in configure.local.example, that BINM_SOELIM is
> the name of the soelim command.

Here, you found a real bug.
Fixed in CVS!

> Interestingly, in a recursive
> case-insensitive search of the source code for "soelim", I could not
> determine how man(1) invokes soelim(1),

It never does.  The mandoc toolbox doesn't require soelim(1) for
any particular purpose.  It is just provided as an additional,
stand-alone tool in case anybody wants to call it manually for
whatever reasons.

> or tells a *roff implementation to invokes its variant
> of soelim(1) (but I didn't look very hard).

The mdoc version of man(1) never calls any external roff(7)
implementation, so it never needs to tell anybody about soelim(1).

> Also, the tbl.3 manual page is installed without a prefix or suffix.

Does that conflict with anything?  With what, specifically?

> Additionally, the 'install' pseudo-target creates
> "${INSTALLATION_PREFIX}/share/examples/mandoc", but does not install
> any example files into it. Question: Is it an obsolete directory or do
> other packages expect this directory to exist? (and, if so, why)

It is obsolete, and i just deleted it.

> % cat > configure.local << __EOF__
> 
> MANPATH_DEFAULT="${MANPATH}"

OUCH, don't do that, don't use data from the environment in
configure.local, use constant data instead.

Otherwise, you get erratic build results depending on whatever
the user happens to have set in their shell.

Thanks!
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2015-11-07 13:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07  6:08 Peter Bray
2015-11-07 13:34 ` Ingo Schwarze [this message]
2015-11-07 23:13   ` Peter Bray

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151107133439.GC10393@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    --cc=pdb_ml@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).