From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5665 invoked by alias); 8 Jul 2014 09:47:49 -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 5647 invoked by uid 89); 8 Jul 2014 09:47:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TBC autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 08 Jul 2014 09:47:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s689leYK029342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Jul 2014 05:47:40 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s689lbks031171; Tue, 8 Jul 2014 05:47:39 -0400 Message-ID: <53BBBE39.6040904@redhat.com> Date: Tue, 08 Jul 2014 09:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eli Zaretskii , Joel Brobecker CC: mingjie.xing@gmail.com, gdb-patches@sourceware.org Subject: Re: [patch] Share options between info and man page References: <8338fc1wed.fsf@gnu.org> <53983FFA.6020909@redhat.com> <53A82F8B.7080507@redhat.com> <83wqc6qp2r.fsf@gnu.org> <20140707141843.GA6038@adacore.com> <83y4w5chra.fsf@gnu.org> In-Reply-To: <83y4w5chra.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg00145.txt.bz2 On 07/07/2014 04:26 PM, Eli Zaretskii wrote: > Frankly, I just don't know what to do with this patch. > > I don't know enough Perl to judge the texi2pod.pl patch, and don't > intend to learn Perl just for that purpose. I didn't know about texi2pod.pl until Mingjie's patch, nor did I know we had it in the tree under etc/. Looking around, AFAICS, the file is maintained in GCC, as indicated in its header: "# This file is part of GCC.". 'git log' also shows entries like: Move from gcc: ... * texi2pod.pl: Import latest version from GCC. GCC's version has a few changes from 2010 that our copy doesn't have. I think we should start by updating our copy from gcc/upstream. And then the etc/ patch should be sent to gcc-patches@ (CCing gdb-patches@). Mingjie, would you like to champion that? > On top of that, this > whole "produce man pages from Texinfo" business was sold to us on the > assumption that "it makes maintenance simpler" (see > https://sourceware.org/ml/gdb-patches/2013-02/msg00290.html and the > discussions around it). To me this means that we put a bunch of > telltale markers into the Texinfo files, add a few Makefile rules, and > promptly forget everything we knew about that. > > But now it sounds like this arrangement is not simple at all, that we > need non-trivial changes to follow (which will probably stump someone > at some point, and perhaps even be changed and break the man-page > generation), we need to maintain texi2pod.pl, and whatnot else. I found some documention on texi2pod.pl here: https://gcc.gnu.org/onlinedocs/gccint/Man-Page-Generation.html Sounds like we actually want '@table @gcctabopt'. > So I'm beginning to doubt that this is for the better. I think the benefits once this is in place outweigh the hurdle we're going through. I'd rather have a synced man page with the occasional odd formatting (that gets fixed eventually) than having to keep the two texts in sync manually. -- Pedro Alves