From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20087 invoked by alias); 31 Mar 2012 08:30:32 -0000 Received: (qmail 20067 invoked by uid 22791); 31 Mar 2012 08:30:31 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Mar 2012 08:30:18 +0000 Received: by werj55 with SMTP id j55so1029891wer.0 for ; Sat, 31 Mar 2012 01:30:17 -0700 (PDT) Received: by 10.180.107.101 with SMTP id hb5mr5337338wib.3.1333182616994; Sat, 31 Mar 2012 01:30:16 -0700 (PDT) Received: from [87.8.100.192] (host192-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.192]) by mx.google.com with ESMTPS id b3sm13798282wib.4.2012.03.31.01.30.14 (version=SSLv3 cipher=OTHER); Sat, 31 Mar 2012 01:30:15 -0700 (PDT) Message-ID: <4F76C08E.6050707@gmail.com> Date: Sat, 31 Mar 2012 08:30:00 -0000 From: Stefano Lattarini MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc@gcc.gnu.org, 11034@debbugs.gnu.org, gdb@sourceware.org, Automake List , binutils@sourceware.org, "Joseph S. Myers" Subject: Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option References: <4F72E239.9010404@gmail.com> <4F7301DD.7090401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00091.txt.bz2 Hi Ian, Joseph, and sorry for the delay. On 03/29/2012 01:43 AM, Ian Lance Taylor wrote: > Stefano Lattarini 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 >> and ). > > 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