Re: doc dirs?

[Guido Draheim]

Russ Allbery wrote:
> 
> Rüdiger Kuhlmann <address@hidden> writes:
> 
> > I'd like to re-kindle the discussion about options for where to put a
> > programs documentation by suggesting the following patch:
> 
> Wouldn't some sort of general facility for adding a new *dir switch for a
> given package be better than adding a bunch of new options that very few
> packages will use (and making --help even longer)?  If the worry is that
> programs will use inconsistent switch names, we can always put a list of
> recommendations into the manual.

just a few thoughts:
a) the helpscreen lists things like sysconfdir or infodir or sharedstatedir
   but many packages don't use these. They are just confusing, nothing else.
   Possibly just there so they can propagate to sub-configures...
b) I see packages to put dirpath-settables as --with-htmldir options, or
   possibly with a different name, e.g. --with-html-dir. It is inconsistent
   and it should be stopped. We want dist-makers to be able to call all 
   the ac' configures with a predefined option-set and have unused ignored.
c) propagate with-options to sub-configure, silently doing it even for
   unknown options, same with the current set of dirpaths, propagate them,
   even if toplevel doesn't used them. nice thing, isn't it. Align the
   functionality of both. Kinda AC_ARG_DIR to be along AC_ARG_WITH (and
   AC_ARG_VAR)?  Looks easy, but probably isn't...
d) combine a/c with an underlying fhs/gcs scheme for knownpaths,
   AC_USE_DIR(synconf sharedstate), don't add it to local subst/help
   by default, but use the knownpath from the standards if a USE_DIR
   is seen. b/c means to accept every --*dir silently for sub-configures.
*) looks like far future anyway... but parts of it could be done next -
   especially extending the --*dir detection through a dedicated macrocall!
   Still need to silenently accept/propagate unknown --*dir options as a 
   known behaviour, needs to be agreed on...