[Top][All Lists]

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

bug#7655: conditional _TEXINFOS should be supported

From: Ralf Wildenhues
Subject: bug#7655: conditional _TEXINFOS should be supported
Date: Thu, 16 Dec 2010 21:02:29 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

[ no need to keep bug-automake@ in Cc:; debbugs takes care of that ]

Hello Jack,

* Jack Kelly wrote on Thu, Dec 16, 2010 at 08:42:52PM CET:
> On Fri, Dec 17, 2010 at 6:41 AM, Jack Kelly wrote:
> > On Fri, Dec 17, 2010 at 6:09 AM, Ralf Wildenhues wrote:
> >> if COND
> >> info_TEXINFOS = foo.texi
> >> foo_TEXINFOS = bar.texi
> >> nodist_info_TEXINFOS = generated.texi
> >> endif
> >>
> >> should work to generate and install foo.{info,pdf,...} only if COND,
> >> but distribute foo.texi and bar.texi always.  Similar with
> >> generated.texi (except for distribution, of course).
> >
> > Disagree. foo.info should always be built, because it goes into `make
> > dist'.

Ah, a piece of logic I didn't think of.  Hmpf.

I need to reread all the long comments in automake.in, to also take the
info-in-srcdir-or-not complication into account.

> > If you want to limit building for non-specific `make', then
> > make sure that the .info files and such all depend on `make dist', so
> > the tarball is correctly generated.

I want to be able to say "no, I do not want this info file to be built
nor installed" for the user.  This is what (at least some) users need.

Also, some users need to be able to generate .texi files.  I'm not sure
if it is always sufficient to let the maintainer generate them (and ship
them plus their .info files).

> Further thoughts on the above: The maintainer should always have
> access to `texinfo', and the user should never have to rebuild .info
> files, so it seems OK to me if they're not blocked when COND is false.

I don't understand what you mean with "blocked" nor with "access to


reply via email to

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