bug#7657: TEXINFOS primary accepts too many prefixes.

[Stefano Lattarini]

On Friday 17 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Thu, Dec 16, 2010 at 10:52:10PM CET:
> > Currently, the TEXINFOS primary accept *all* the standard automake
> > builtin prefix dirs (from `lib' and `bin' to `pkglibexec' and
> > `sysconf').
> > 
> > IMHO it should accept only the `info' prefix (maybe also `doc'? but
> > I'd rather say no).
> 
> Let's turn the question around: why cripple the developer unnecessarily?
> 
> The mind set is that: the user of a package is smarter than the
> developer (that's why the former should be able to override the
> configure settings etc), and the developer is smarter than the
> Automake developer: the latter cannot know all possible ways in
> which things may be put together.
> 
> The current target directory limitations result mostly from
> technical limitations.
>
> 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

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
does not.  This is by design, and it's a good design IMHO.

Regards,
   Stefano