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