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
