bug#7657: TEXINFOS primary accepts too many prefixes.

[Ralf Wildenhues]

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET:
> On Friday 17 December 2010, Ralf Wildenhues wrote:
> > For example, I can easily imagine a package having normal texinfo
> > manuals, but also a developer's manual that maybe should end up
> > in an internal directory elsewhere (or only its PDF?).  We aim to
> > not just support strict GNU style packages.
> >
> Note that we won't really forbid it, we'll just require the developer
> to be more explicit/verbose about what he's doing if that's a thing
> that "smells fishy" to automake; for example, automake will be required
> to error out on this:
>   man_TEXINFOS = foo.texi
> but not on this:
>   xmandir = $(mandir) # we want info files installed in $(mandir) because ...
>   xman_TEXINFOS = foo.texi

This workaround is good, but if we require our users to rely on it more,
then I think it should also be documented better.  I didn't find
explicit mention of it in the manual.
(And the inline comment is of course not ok ;-)

> And note that the current automake already behaves this way with other
> primaries such as `PROGRAMS', so that:
>   lib_PROGRAMS = foo
> gives an error, but:
>   foodir = $(libdir)
>   foo_PROGRAMS = foo

This snippet is most likely not what you want, as it will cause foo to
be installed at install-data rather than install-exec time.

> does not.  This is by design, and it's a good design IMHO.

OK, so I'm ok with excluding combinations that are obviously bogus (MANS
and TEXINFOS in bindir, for example, or TEXINFOS in mandir).  libdir is
questionable because with nobase_, packages can and do install all kinds
of stuff below $(libdir)/$(PACKAGE) (or $(pkglibdir), but we do not
require our users to use that name).

Thanks,
Ralf