Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stefano Lattarini <stefano.lattarini@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc@gcc.gnu.org, 11034@debbugs.gnu.org, gdb@sourceware.org,
	 Automake List <automake@gnu.org>,
	binutils@sourceware.org,
	"Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Date: Sat, 31 Mar 2012 08:30:00 -0000	[thread overview]
Message-ID: <4F76C08E.6050707@gmail.com> (raw)
In-Reply-To: <mcr1uoci96g.fsf@dhcp-172-18-216-180.mtv.corp.google.com>

Hi Ian, Joseph, and sorry for the delay.

On 03/29/2012 01:43 AM, Ian Lance Taylor wrote:
> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
>>> (I think avoiding info documentation being built in the source directory,
>>> so that builds could use a non-writable source directory, may have been
>>> one part).
>>>
>> There is probably some hack to obtain this effect (it's tested in the testsuite
>> somewhere), but my opinion is that if you distribute the generated info files
>> you should also have them generated in the source directory, to avoid nasty
>> surprises (for a similar issue, involving yacc and lex, see automake bug#10852,
>> in particular messages <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#14>
>> and <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#15>).
> 
> It's useful to be able to include .info files in releases so that people
> can build the releases without having to have makeinfo installed.
>
I agree on this (as did past Automake maintainers -- in fact Automake distributes
generated info files be default).  But I also think that, whenever you distribute
generated files, the most sensible and safer thing to do is to have them generated
in the srcdir and not in the builddir, so that the tree from a VCS checkout and
the one extracted from a distribution tarball are similar and consistent (I held
a different opinion once, but Akim Demaille later changed my mind on this).

> It's important that it be possible to build with the sources on a
> read-only disk.
>
Yes, and in fact "make distcheck" verifies that this is possible.  However,
assuming it is also possible to *hack* a package with the sources on a read
only disk is not warranted.

In conclusion, I see two possible sane approaches w.r.t. the handling of
generated info files:

  - Have them distributed (automake's default).  This means that they will
    be build in the srcdir, not in the builddir: of course, this only affects
    the maintainer, since for a user that builds the package from a tarball
    those files should *not* be rebuilt, hence there is no problem even if
    the user's srcdir is read-only.

  - Don't distribute the generated info files.  To obtain this effect, it is
    enough to list the generated into files in the CLEANFILES variable (see
    for example the tests 'txinfo23', 'txinfo24' and 'txinfo25' in the automake
    testsuite).  In this case, the user will have to to have the 'makeinfo'
    program available to build them.

Regards,
  Stefano


  reply	other threads:[~2012-03-31  8:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28 10:05 Stefano Lattarini
2012-03-28 11:25 ` Joseph S. Myers
2012-03-28 12:20   ` Stefano Lattarini
2012-03-28 12:29     ` Joseph S. Myers
2012-03-28 13:02       ` Stefano Lattarini
2012-03-28 23:43     ` Ian Lance Taylor
2012-03-31  8:30       ` Stefano Lattarini [this message]
2012-03-31  9:08         ` bug#11034: " Alfred M. Szmidt
2012-03-31 10:14           ` Stefano Lattarini
2012-04-04 13:18             ` Joseph S. Myers
2012-04-05 12:04               ` Stefano Lattarini
     [not found]           ` <4F76D8F2.8050804__46768.5595191599$1333188914$gmane$org@gmail.com>
2012-04-02 14:26             ` Tom Tromey
2012-04-02 15:04               ` Stefano Lattarini
2012-04-02 15:17                 ` Tom Tromey
2012-04-02 15:30                   ` Stefano Lattarini
     [not found]                   ` <4F79C5F2.2020807__46832.8654104427$1333380662$gmane$org@gmail.com>
2012-04-02 19:37                     ` Tom Tromey
2012-04-02 19:51                       ` Stefano Lattarini
     [not found]                       ` <4F7A0341.9050305__49963.8538728051$1333396325$gmane$org@gmail.com>
2012-04-02 20:19                         ` Tom Tromey
2012-04-02 20:50                           ` Stefano Lattarini
2012-04-02 21:10                             ` Ian Lance Taylor
2012-04-03 20:04                               ` Stefano Lattarini
2012-04-03 20:05                                 ` Stefano Lattarini
2012-04-03 20:29                                   ` Stefano Lattarini
2012-04-03 20:40                                     ` Tom Tromey
2012-04-04  7:43                                       ` Stefano Lattarini
2012-04-03 21:08                                 ` Ian Lance Taylor
2012-04-03 21:40                                 ` Pedro Alves
2012-04-03 23:53                                   ` Miles Bader
2012-04-04  7:47                                     ` Stefano Lattarini
2012-04-04  9:03                                     ` Pedro Alves
2012-04-03  8:23                             ` Joern Rennecke
2012-03-31 11:39     ` Stefano Lattarini
2012-03-31 16:42       ` bug#11034: " Stefano Lattarini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F76C08E.6050707@gmail.com \
    --to=stefano.lattarini@gmail.com \
    --cc=11034@debbugs.gnu.org \
    --cc=automake@gnu.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=iant@google.com \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox