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

Previous Next

To reply to this bug, email your comments to 7657 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: TEXINFOS primary accepts too many prefixes.
Date: Thu, 16 Dec 2010 22:52:10 +0100

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

Thanks,
   Stefano

Message #8 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: bug#7657: TEXINFOS primary accepts too many prefixes.
Date: Fri, 17 Dec 2010 06:49:50 +0100

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

Cheers,
Ralf

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7657 <at> debbugs.gnu.org
Subject: Re: bug#7657: TEXINFOS primary accepts too many prefixes.
Date: Fri, 17 Dec 2010 12:19:40 +0100

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

Message #14 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: bug#7657: TEXINFOS primary accepts too many prefixes.
Date: Sun, 19 Dec 2010 12:03:20 +0100

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET:
> On Friday 17 December 2010, Ralf Wildenhues wrote:
> > 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

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.
(And the inline comment is of course not ok ;-)

> 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

This snippet is most likely not what you want, as it will cause foo to
be installed at install-data rather than install-exec time.

> 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) (or $(pkglibdir), but we do not
require our users to use that name).

Thanks,
Ralf

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7657 <at> debbugs.gnu.org
Subject: TEXINFOS and MANS primaries accepts too many prefixes (was: Re:
	bug#7657: TEXINFOS primary accepts too many prefixes.)
Date: Tue, 21 Dec 2010 13:55:39 +0100

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

> > 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
> 
> This snippet is most likely not what you want, as it will cause foo to
> be installed at install-data rather than install-exec time.
>
Right.  It should have been something like:

  fooexecdir = $(libdir)
  fooexec_PROGRAMS = foo
 
To quote the automake manual:
 ``Any variable using a user-defined directory prefix with ‘exec’ in the
   name (e.g., myexecbin_PROGRAMS) is installed by install-exec. All other
   user-defined prefixes are installed by install-data.''

> > 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
  nobase_pkglib_MANS = foo.1
  inst_pkglib_MANS = foo.1
  inst_nobase_pkglib_MANS = foo.1
  mylibdir = $(libdir)/$(PACKAGE)
  mylib_MANS = foo.1
  nobase_mylib_MANS = foo.1
  inst_mylib_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
  nobase_pkglib_TEXINFOS = foo.texi
  inst_pkglib_TEXINFOS = foo.texi
  inst_nobase_pkglib_TEXINFOS = foo.texi
  mylibdir = $(libdir)/$(PACKAGE)
  mylib_TEXINFOS = foo.texi
  nobase_mylib_TEXINFOS = foo.texi
  inst_mylib_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".  More investigation
needed.

> (or $(pkglibdir), but we do not require our users to use that name).
>
> Thanks,
> Ralf
> 

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.

Regards,
   Stefano

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

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7657 <at> debbugs.gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Subject: Re: bug#7657: TEXINFOS and MANS primaries accepts too many prefixes
Date: Fri, 24 Dec 2010 12:17:09 +0100

On Tuesday 21 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Dec 21, 2010 at 01:55:39PM CET:
> > 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!
>
Well, I should have done more research up front.  It's obvious that the
above does not work as I expected, because, reading from the automake
manual (not a literal excerpt):

  Sometimes an info file actually depends on more than one .texi file.
  For instance, in GNU Hello, hello.texi includes the file gpl.texi.
  You can tell Automake about these dependencies using a foo_TEXINFOS
  variable.  Here is how GNU Hello does it:
    info_TEXINFOS = hello.texi
    hello_TEXINFOS = gpl.texi

So there's no "real" bug here, just a badly chosen naming convention.
Maybe Automake might be modified to instead use something like:
    info_TEXINFOS = hello.texi
    hello_TEXINFOSOURCES = hello.texi gpl.texi
and/or:
    info_TEXINFOS = hello.texi
    EXTRA_hello_TEXINFOSOURCES = gpl.texi
and start to warn above the old TEXINFOS usage.  Then, starting from
Automake 1.13, the obsoleted "foo_TEXINFOS = bar.texi" idiom could
be removed.

An obvious advantage of this new convention would be its similarity
to the conventions already in place for the PROGRAMS and LIBRARIES
primaries.

Poll for automake users: would you find this new convention worthwhile,
or is the current behaviour Good Enough?

> > 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.
> 
And now I'm going to (try to) separate the two bugs again, because, as
it just turned out, they really are about two completely unrelated
issues.  D'oh.

Regards,
   Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Sebastian Freundt <devel <at> fresse.org>,
 9506 <at> debbugs.gnu.org
Cc: bug-automake <at> gnu.org, 7657 <at> debbugs.gnu.org
Subject: TEXINFOS primary and nodist_ (was: Re: makeinfo in VPATH builds fails)
Date: Thu, 15 Sep 2011 13:34:23 +0200

[Message part 1 (text/plain, inline)]

Submitter: Sebastian Freundt <devel <at> fresse.org>
thanks

Reference:
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9506>

On Thursday 15 September 2011, Sebastian Freundt wrote:
> Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>
> > The main point is that if you're distributing you `.info' files, you should
> > ensure that they are *not* rebuilt when building from a distribution tarball
> > (as that would wreak havoce with at least FreeBSD make).  OTOH, if you *want*
> > them to be rebuilt, you should *not* distribute them, and *also* add them to
> > CLEANFILES; in this case automake will build them in the buiilddir (if it
> > doesn't, than that's a bug we should fix ASAP).
> >
> > I've marked this bug closed as "wontfix", but feel free to continue the
> > discussion here if you have further doubts to clarify or ideas to contribute.
> 
> 
> Hi Stefano,
>
> I've followed your suggestions, and prefixed the TEXINFOS with `nodist_'
> and added them to CLEANFILES, however the .info file is now neither built
> nor installed (even upon make install-info).
>
Hmpf, yes, this is another limitation/incompatibility of the TEXINFOS
primary; the only ways TEXINFOS can by used are:

  # Will cause generation of foo.info, foo.pdf, etc.
  info_TEXINFOS = foo.texi
  # Will declare that these files ae required when building `foo.texi'
  foo_TEXINFOS = bar.texi baz.texi

So, when automake sees nodist_TEXINFOS, it thinks that it just lists extra
`.texi' files required by `nodist.texi' ... And it doesn't even warn that
`nodist.texi' is not really used anywhere!

There is already a bug report about this situation:
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7657>
but I had forgotten about it.  Thanks for reminding me!

> 
> In my case the .info files should be rebuilt and not distributed as they
> contain partially auto-generated content.
>
OK.  Maybe you might use a dist-hook to remove the `.info' files not
intended for distribution from the distdir, just before the distribution
tarball is created.  See:
 <http://www.gnu.org/software/automake/manual/html_node/The-dist-Hook.html>

> Another bug report?
>
Good idea.  I've already opened it (hopefully in your name, otherwise I'll
fix that later).
 
> Cheers
> Sebastian
> 

Thanks,
  Stefano

[Message part 2 (text/html, inline)]

Previous Next

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