From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-40613-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 20552 invoked by alias); 31 Mar 2012 09:08:57 -0000
Received: (qmail 20528 invoked by uid 22791); 31 Mar 2012 09:08:55 -0000
X-SWARE-Spam-Status: No, hits=-5.2 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Mar 2012 09:08:42 +0000
Received: from ams by fencepost.gnu.org with local (Exim 4.71)	(envelope-from <ams@gnu.org>)	id 1SDuIY-0004aQ-0U; Sat, 31 Mar 2012 05:08:38 -0400
Date: Sat, 31 Mar 2012 09:08:00 -0000
Message-Id: <E1SDuIY-0004aQ-0U@fencepost.gnu.org>
From: ams@gnu.org (Alfred M. Szmidt)
To: Stefano Lattarini <stefano.lattarini@gmail.com>
CC: iant@google.com, gcc@gcc.gnu.org, 11034@debbugs.gnu.org,	gdb@sourceware.org, automake@gnu.org, binutils@sourceware.org,	joseph@codesourcery.com
In-reply-to: <4F76C08E.6050707@gmail.com> (message from Stefano Lattarini on	Sat, 31 Mar 2012 10:30:06 +0200)
Subject: Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Reply-to: ams@gnu.org
References: <4F72E239.9010404@gmail.com>	<Pine.LNX.4.64.1203281121190.12161@digraph.polyomino.org.uk>	<4F7301DD.7090401@gmail.com> <mcr1uoci96g.fsf@dhcp-172-18-216-180.mtv.corp.google.com> <4F76C08E.6050707@gmail.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2012-03/txt/msg00092.txt.bz2

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

This has always been the right way to do things.

     - Don't distribute the generated info files.  [...]  In this
       case, the user will have to to have the 'makeinfo' program
       available to build them.

Please don't do this, it causes all kinds of headaches, like the small
fact that makeinfo will now be required to bootstrap.