Re: [Nmh-workers] A --prefix friendly install

[Ken Hornstein]

>This layout isn't very friendly with 'configure --prefix=/usr/local'.
>
>I would like to adopt a more Berkeley-ish layout. Specifically, moving
>.../etc/* to .../etc/nmh/*, and .../lib/* to .../libexec/nmh/*.  This
>more closely follows current filesystem layouts, and for those which
>don't, we still avoid spamming their existing directories.  And in the
>default case, under /usr/local/nmh, nothing is upset internally.

Other than people who have paths hardcoded for /usr/local/nmh/lib into
their programs.  We should coordinate with exmh and MH-E people to make
sure that doesn't break things.  Maybe we can even get Valdis to crank
out a new release of exmh?

Our backend programs in lib going to libexec, yeah, that's pretty
standard.  But I'm torn about making things with a "nmh" prefix as a
default (e.g., etc/nmh).  I'd rather move toward us behaving like every
other autoconf package.  And I guess I'm fine with us "spamming"
directories like /usr/local; our uninstall target works fine, and a lot
of people are using a packaging system anyway.  Power users can override
this behavior easily with autoconf switches.  Of course, the counter-point
is that you can get back the old behavior easily as well.  I don't have
a good counter-argument to that, I will admit.

>My only concern is with where the manpages get installed.  Currently we
>put them under .../share/man/.  That seems to be the autoconf default
>location.  But for most of the systems I have access to, versions of man
>that adapt their search path based on $PATH search on ../man for every
>.../bin they find in $PATH.  So I'm wondering if it might not be better
>to install under $prefix/man rather than $prefix/share/man by default?
>We might have to tune this in configure.ac, but I think installing in
>.../man will work for most OSes.

I kinda thought nowadays that ../share/man was relatively standard.  But
I see what you mean about "man" commands supporting looking in people's
paths, and I wasn't aware of that.

I'd be happy with a --with-traditional-paths flag to autoconf that put
things back the "old" way.  I'm less happy about the "new" paths not
conforming to autoconf standards, but I don't have super strong feelings
about it.

--Ken