GNU bug report logs - #7657
TEXINFOS primary accepts too many prefixes

Previous Next

Full log

Message #24 received at 7657 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7657 <at> debbugs.gnu.org
Subject: Re: TEXINFOS and MANS primaries accepts too many prefixes
Date: Tue, 21 Dec 2010 20:49:58 +0100

* Stefano Lattarini wrote on Tue, Dec 21, 2010 at 01:55:39PM CET:
> On Sunday 19 December 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET:
> > >   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 ...)

I don't see how they were ever not problematic.  Well, at least given
the autoconf.texi general warnings about comments in makefiles.

> > > 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
[...]
>   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
[...]
>   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".

Ah.  I was missing something.  This changes the question quite a bit.
If we don't take action upon all the other combinations, then it makes
more sense to warn about them.  Thanks for the research!

> 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.

Cool.

Thanks,
Ralf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.