GNU bug report logs -
#7657
TEXINFOS primary accepts too many prefixes
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 13 years and 276 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.