Re: target-delegates.c needs some TLC [was Re: [OB PATCH] target.h (to_traceframe_info): Fix TARGET_DEFAULT_RETURN]

[Pedro Alves <palves at redhat dot com>]

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 <palves@redhat.com> 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