Re: Make GDB build with python 2.4 again.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

>> Meanwhile, on 'archer-tromey-python':

Pedro> Sorry, but if you know something is broken in code that's in the FSF
Pedro> tree, you should post a patch there.  You can't expect me to track what's
Pedro> going on the archer branches.

That seems reasonable.  In this case, I didn't consider that the patch
might be useful upstream, or I would have asked Paul to send it
upstream.  Sorry about that.

>> Note that in current gdb/python sources, additional changes
>> are required for python2.4 if Py_ssize_t isn't fixed as above ...

Pedro> That looks strange, since ssize_t isn't usually the same size
Pedro> of int.

My belief is that Py_ssize_t is a 2.5 introduction, and places using
Py_ssize_t used to use int.  That is why the patch was written the way
it was.

>> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
>> >
>> >        * python/python-value.c (value_object_methods)
>> >        (value_object_as_number, value_object_as_mapping): Move to bottom
>> >        of file.

Paul> Why?

Pedro> To avoid all the forward references, so that we don't have to change
Pedro> two places whenever an interface changes, or things like these happen.

This is an issue -- a minor one -- for three reasons.

First, in general, it is better to commit code rearrangements and bug
fixes as separate patches.

Second, in this particular instance, this code is actively being
worked on separately and being merged in.  Changes to the trunk mean
back-porting the changes and redoing the patch branch -- adding work
for, IMO, little gain.  This is related to the first point in that
this patch has to be edited before backporting.

Finally, there is nothing to say that the preferred gdb style is to
avoid forward declarations.  So, we picked a style we liked -- not
unintentionally, at least on my part, but because I like having the
"class definition" at the top, followed by method implementations,
followed by the initialization code.  All the python code follows this
outline.

I'll look at moving this change to the python branch tomorrow (unless
someone gets there first).  If you want all the forward declarations
removed from the python code, please let me know, and I'll implement
that on the branch as well.

Tom