From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29733 invoked by alias); 21 Mar 2014 16:25:09 -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 29721 invoked by uid 89); 21 Mar 2014 16:25:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham 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 ESMTP; Fri, 21 Mar 2014 16:25:07 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2LGOx89029984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Mar 2014 12:24:59 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2LGOuvA018945; Fri, 21 Mar 2014 12:24:57 -0400 Message-ID: <532C67D8.6070702@redhat.com> Date: Fri, 21 Mar 2014 16:25:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Doug Evans CC: Yao Qi , Tom Tromey , Hui Zhu , gdb-patches ml Subject: Re: target-delegates.c needs some TLC [was Re: [OB PATCH] target.h (to_traceframe_info): Fix TARGET_DEFAULT_RETURN] References: <531A110B.4060502@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00524.txt.bz2 Sorry, dropped the ball on this one. On 03/09/2014 11:16 PM, Doug Evans wrote: > On Fri, Mar 7, 2014 at 10:33 AM, Pedro Alves wrote: >> I don't see a problem there. automake is perl as well, for instance, >> and it's common for --enable-maintainer-mode to trigger automake/aclocal. > > I recognize the *technical* need of having perl installed for use by > automake, but that's not the context in which my comment is phrased. > How much perl do I need to know in order to use automake? None. Just as no perl knowledge is required to run to use new script. > My comment is phrased the way it is because I was not prepared to > a-priori declare one needs to know perl when --enable-maintainer-mode > is turned on: Note --enable-maintainer-mode is irrelevant in that consideration. If the file needs regeneration, it'll need it no matter whether --enable-maintainer-mode is in effect. --enable-maintainer-mode just runs makes generator tools run automatically based on timestamps. (and it's not on by default AFAIK because unpacking release source tarballs may break the timestamps and the makefile would otherwise try to regenerate the generated files). > If the user turns it on and that exposes a > problem/issue/whatever with target-delegates.c, then I expect the user > to have to deal with it, it's one more piece if implementation > infrastructure we've imposed on developers. Today, if a developer > turns on --enable-maintainer-mode I'm not going to apologize for > having imposed on them some minimal comfortability with autoconf. I think it's no issue really. I myself don't know that much perl, but I assume that if I do stumble on some problem, it shouldn't be hard to fix, or if is, I'll just ask for help. The generated file is checked into the tree. If joe-hacker changes target.h and the generator fails, I'm sure joe-hack can just report the issue, tweak the generated file by hand, and move on until someone else fixes the issue. Perl hackers shouldn't be hard to find. This is not that different IMO from say, finding a bug in gdbarch.sh. Now I wouldn't expect random-joe-hacker to know that much about debugging shell scripts either. > Typically one needn't know very much (hopefully just having the right > version installed will solve their problem), but IME that's not always > the case. > Help is always at hand of course, still there's a non-trivial > additional load being imposed on developers, and I'm not prepared to > a-priori impose it. I honestly believe problems with the script itself will be quite rare. If it turns out more problematic than expected, we can always consider rewriting it in another language then. -- Pedro Alves