bug#7657: TEXINFOS and MANS primaries accepts too many prefixes (was: Re: bug#7657: TEXINFOS primary accepts too many prefixes.)

[Stefano Lattarini]

On Sunday 19 December 2010, Ralf Wildenhues wrote:
> * 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.
>
Agreed.

> (And the inline comment is of course not ok ;-)
>
(Maybe it's time to deprecate them too in the manual ...)

> > 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.
>
Right.  It should have been something like:

  fooexecdir = $(libdir)
  fooexec_PROGRAMS = foo
 
To quote the automake manual:
 ``Any variable using a user-defined directory prefix with ‘exec’ in the
   name (e.g., myexecbin_PROGRAMS) is installed by install-exec. All other
   user-defined prefixes are installed by install-data.''

> > 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)
>
Am I missing something here?  Because currently all of:

  pkglib_MANS = foo.1
  nobase_pkglib_MANS = foo.1
  inst_pkglib_MANS = foo.1
  inst_nobase_pkglib_MANS = foo.1
  mylibdir = $(libdir)/$(PACKAGE)
  mylib_MANS = foo.1
  nobase_mylib_MANS = foo.1
  inst_mylib_MANS = foo.1
  inst_nobase_mylib_MANS = foo.1

do *not* cause foo.1 to be installed (might this be another automake
bug? I need to investigate).

And similarly, for texinfo, all of:

  pkglib_TEXINFOS = foo.texi
  nobase_pkglib_TEXINFOS = foo.texi
  inst_pkglib_TEXINFOS = foo.texi
  inst_nobase_pkglib_TEXINFOS = foo.texi
  mylibdir = $(libdir)/$(PACKAGE)
  mylib_TEXINFOS = foo.texi
  nobase_mylib_TEXINFOS = foo.texi
  inst_mylib_TEXINFOS = foo.texi
  inst_nobase_mylib_TEXINFOS = foo.texi

do *not* cause foo.into to be even *built* with "make info"!  It gets
build only if one uses "info_TEXINFOS = foo.texi".  More investigation
needed.

> (or $(pkglibdir), but we do not require our users to use that name).
>
> Thanks,
> Ralf
> 

BTW, I'm going to merge this bug with bug#7656 (and then retitle both
of them), otherwise we will be forced to incur in a lot of useless
duplication among the two discussions.  Sorry for not havig reported
these two related issues with a single report right away.

Regards,
   Stefano