From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126083 invoked by alias); 14 Sep 2018 08:28:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126073 invoked by uid 89); 14 Sep 2018 08:28:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=realize X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Sep 2018 08:28:49 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0jT1-0006Fu-Vd for gdb-patches@sourceware.org; Fri, 14 Sep 2018 04:28:47 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0jT1-0006Fb-Nc; Fri, 14 Sep 2018 04:28:43 -0400 Received: from [176.228.60.248] (port=2611 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g0jT1-0001Ht-Az; Fri, 14 Sep 2018 04:28:43 -0400 Date: Fri, 14 Sep 2018 08:28:00 -0000 Message-Id: <83pnxgjxe7.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <20180914042946.29248-1-tom@tromey.com> (message from Tom Tromey on Thu, 13 Sep 2018 22:29:46 -0600) Subject: Re: [RFA] Update gdb's configure instructions References: <20180914042946.29248-1-tom@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00451.txt.bz2 > From: Tom Tromey > Cc: Tom Tromey > Date: Thu, 13 Sep 2018 22:29:46 -0600 > > This also removes the PROBLEMS file, as it seems unused. It hasn't > been updated since before the 7.3 release. How about replacing PROBLEMS with a file that just points people to the GDB Bugzilla, and perhaps tells how to search Bugzilla for GDB problems that are still not solved in version X.Y.Z of GDB? > The README file seems to have been generated from the Texinfo at some > point in the past. I did not continue this, but instead edited it > separately. Ideally, README should include some details about optional build features that allow the user to decide which options to request. The help text provided by gdb/configure is too terse, and I'm not even sure many people realize that they need to run "./gdb/configure --help" rather than the top-level configure script. Perhaps README should at least tell that. Bonus points for describing other optional build features with enough information for users to understand whether each option will be useful for them. For example, some features are only relevant for ELF systems, others only for GNU/Linux, etc., but there's no info on that in README or "configure --help". > When submitting a bug, please include the GDB version number, and > how you configured it (e.g., "sun4" or "mach386 host, > -i586-intel-synopsys target"). Since GDB now supports so many > +i586-intel-synopsys target"). Since GDB supports so many > different configurations, it is important that you be precise about > this. If at all possible, you should include the actual banner > that GDB prints when it starts up, or failing that, the actual Should this text mention the gdb --config option and the corresponding "show configuration" command? > +@item Guile > +@value{GDBN} can be scripted using GNU Guile. @xref{Guile}. By > +default, @value{GDBN} will be compiled if the Guile libraries are > +available. Something is missing in the last sentence. Also, I'm not sure "if the Guile libraries are available" is explicit enough. How about if the Guile libraries are installed and are found by the configure script > +On systems without @code{iconv}, you can install GNU Libiconv. If you > +have previously installed Libiconv, you can use the > +@option{--with-libiconv-prefix} option to configure. I would suggest here to say explicitly that if libiconv is installed in a standard place, then the configure script will find it and compile GDB with it. > +@value{GDBN}'s top-level @file{configure} and @file{Makefile} will > +arrange to build Libiconv if a directory named @file{libiconv} appears > +in the top-most source directory. If Libiconv is built this way, and > +if the operating system does not provide a suitable @code{iconv} > +implementation, then the just-built library will automatically be used > +by @value{GDBN}. One easy way to set this up is to download GNU > +Libiconv, unpack it, and then rename the directory holding the > +Libiconv source code to @samp{libiconv}. I think it is better to say explicitly "unpack it inside the top-level directory of the GDB source tree", instead of just "unpack it". > +@item lzma > +@value{GDBN} can support debugging sections that are compressed with > +the LZMA library. @xref{MiniDebugInfo}. If this library is not > +included with your operating system, you can find it in the xz package > +at @url{http://tukaani.org/xz/}. If it is installed in an unusual > +path, you can use the @option{--with-lzma-prefix} option to specify > +its location. Again, before talking about lzma being installed in an unusual place, I'd suggest to say something about its being installed in the usual place, i.e. that the configure script will find it automatically. > +@item Python > +@value{GDBN} can be scripted using Python language. @xref{Python}. > +By default, @value{GDBN} will be compiled if the Python libraries are > +available. Same problem in the last sentence here as in the Guile section above. > +You can install @code{@value{GDBP}} anywhere. The best way to do this I think this should be "GDBN", not "GDBP". Thanks.