[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.
Cool.
Thanks,
Ralf