[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7657: TEXINFOS and MANS primaries accepts too many prefixes

From: Ralf Wildenhues
Subject: bug#7657: TEXINFOS and MANS primaries accepts too many prefixes
Date: Tue, 21 Dec 2010 20:49:58 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]