Hmmm. I'm trying to build wxPython 2.6.2.1 against the system wxGTK 2.6.2,
and it won't. There may be further obstacles, but the immediate one is this
difference between real wxGTK 2.6.2 and the one shipped with wxPython
(apparently CVS snapshot?):
Urk. Any idea about what to do about this? I really don't want to go down
the road of providing a duplicate (separate but unequal) wxGTK specially for
wxPython, but then, people are apparently going to expect wxPython 2.6.2.1
to have this.
Is my best bet going to be to dig through the wxPython code and dredge this
out? I guess either regenerating the SWIG stuff, or else with a big kludgy
patch. Any other suggestions? Thanks.
I'm having the same problem trying to update the FreeBSD port, which also uses the standard wxGTK.
···
On 6 Feb 2006, at 21:46, Matthew Miller wrote:
Hmmm. I'm trying to build wxPython 2.6.2.1 against the system wxGTK 2.6.2,
and it won't. There may be further obstacles, but the immediate one is this
difference between real wxGTK 2.6.2 and the one shipped with wxPython
(apparently CVS snapshot?):
Urk. Any idea about what to do about this? I really don't want to go down
the road of providing a duplicate (separate but unequal) wxGTK specially for
wxPython, but then, people are apparently going to expect wxPython 2.6.2.1
to have this.
Is my best bet going to be to dig through the wxPython code and dredge this
out? I guess either regenerating the SWIG stuff, or else with a big kludgy
patch. Any other suggestions? Thanks.
>Urk. Any idea about what to do about this? I really don't want to go down
>the road of providing a duplicate (separate but unequal) wxGTK specially
>for wxPython, but then, people are apparently going to expect wxPython
>2.6.2.1 to have this.
[...]
I'm having the same problem trying to update the FreeBSD port, which
also uses the standard wxGTK.
I discovered that the problem also exists with wxMouseState.
My first cut at patching these out results in a wxPython that segfaults
immediately. Not sure if that's due to a mistake I made or due to some
other incompatible change.
···
On Tue, Feb 07, 2006 at 11:30:53AM +0100, Neal Nelson wrote:
Hmmm. I'm trying to build wxPython 2.6.2.1 against the system wxGTK 2.6.2,
and it won't. There may be further obstacles, but the immediate one is this
difference between real wxGTK 2.6.2 and the one shipped with wxPython
(apparently CVS snapshot?):
The 1 at the end of the 2.6.2.1 version number indicates that it is a release made after the 2.6.2(.0) release made by the wxWidgets team. But it can be considered a real release since the 4th component of the version number (called subrelease number) is set and tracked in wx/version.h. The only difference is that there isn't a regular wxGTK tarball made of the subrelease sources.
Urk. Any idea about what to do about this? I really don't want to go down
the road of providing a duplicate (separate but unequal) wxGTK specially for
wxPython, but then, people are apparently going to expect wxPython 2.6.2.1
to have this.
There's no need to make separate libs, just make your wxGTK packages from the 2.6.2.1 sources. This is what Debian, Ubuntu, SuSE and a couple others do. 2.6.2.1 is backwards API compatible with 2.6.2.0, and should be backwards binary compatible too, so any code written for 2.6.2.0 should work fine with 2.6.2.1.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
The 1 at the end of the 2.6.2.1 version number indicates that it is a
release made after the 2.6.2(.0) release made by the wxWidgets team.
But it can be considered a real release since the 4th component of the
version number (called subrelease number) is set and tracked in
wx/version.h. The only difference is that there isn't a regular wxGTK
tarball made of the subrelease sources.
Ah, okay. I'd presumed the .1 was a wxPython subversion number, not an
upstream one. Good to know.
So I can pull that from the wxWidgets CVS. I guess that can be done if need
be, but it kind of breaks from the general-good-principle of sticking to
pristine versions of official stable upstream releases except for security
or other vital fixes. (There must be some good reason wxWidgets doesn't
bother to make "subrelease" source tarballs.)
There's no need to make separate libs, just make your wxGTK packages
from the 2.6.2.1 sources. This is what Debian, Ubuntu, SuSE and a
couple others do. 2.6.2.1 is backwards API compatible with 2.6.2.0, and
should be backwards binary compatible too, so any code written for
2.6.2.0 should work fine with 2.6.2.1.
Okay, thanks.
···
On Tue, Feb 07, 2006 at 09:17:09AM -0800, Robin Dunn wrote:
shows 551 files changed, 28912 insertions(+), 126863 deletions(-). Plus a
diff of the ./include directories shows 327 files changed, 653
insertions(+), 31403 deletions(-).
I see in CVS that there's a "wxPy_2_6_2_1" tag, which is presumably the
point at which your snapshot was taken. But that point doesn't correspond to
the wxWidgets 2.6.2.1 subrelease across all of the source.
···
On Tue, Feb 07, 2006 at 12:31:14PM -0500, Matthew Miller wrote:
On Tue, Feb 07, 2006 at 09:17:09AM -0800, Robin Dunn wrote:
> The 1 at the end of the 2.6.2.1 version number indicates that it is a
> release made after the 2.6.2(.0) release made by the wxWidgets team.
> But it can be considered a real release since the 4th component of the
> version number (called subrelease number) is set and tracked in
> wx/version.h. The only difference is that there isn't a regular wxGTK
> tarball made of the subrelease sources.
Ah, okay. I'd presumed the .1 was a wxPython subversion number, not an
upstream one. Good to know.
So I can pull that from the wxWidgets CVS. I guess that can be done if need
be, but it kind of breaks from the general-good-principle of sticking to
pristine versions of official stable upstream releases except for security
or other vital fixes. (There must be some good reason wxWidgets doesn't
bother to make "subrelease" source tarballs.)
Hmmm. So, I went and did a bit of research as to what others are doing.
Debian seems to have a 2.6.1.2 package as the latest, and as far as I
can tell, they have some weird amalgamated source package which is neither
your tarball nor the one from wxWidgets.org.
Ubuntu doesn't seem to have packages in the supported distro but there are
some in what they call the "Ubuntu Universe". This appears to be the same
situation as with Debian -- source packages of uncertain provenance, and
only up to 2.6.1.2.
Gentoo has 2.6.1.0 as the latest.
So, I think these distributions just haven't dealt with the problem yet.
The latest SuSE development has a wxGTK-2.6.2.1 rpm, and this appears to be
entirely based on your tarball, which I think is an improvement over (what
appears to me to be -- maybe I'm misunderstanding) Debian's approach,
because it at least makes everything consistent, but I don't think is the
direction I want to take for the Fedora package.
I'd really like to get this solved, as the current version in Fedora is
2.4.2.4, and there's much clamor for having the 2.6.x line available.
···
On Tue, Feb 07, 2006 at 12:31:14PM -0500, Matthew Miller wrote:
> There's no need to make separate libs, just make your wxGTK packages
> from the 2.6.2.1 sources. This is what Debian, Ubuntu, SuSE and a
> couple others do. 2.6.2.1 is backwards API compatible with 2.6.2.0, and
> should be backwards binary compatible too, so any code written for
> 2.6.2.0 should work fine with 2.6.2.1.
Okay, thanks.
The 1 at the end of the 2.6.2.1 version number indicates that it is a release made after the 2.6.2(.0) release made by the wxWidgets team. But it can be considered a real release since the 4th component of the version number (called subrelease number) is set and tracked in wx/version.h. The only difference is that there isn't a regular wxGTK tarball made of the subrelease sources.
Ah, okay. I'd presumed the .1 was a wxPython subversion number, not an
upstream one. Good to know.
So I can pull that from the wxWidgets CVS. I guess that can be done if need
be, but it kind of breaks from the general-good-principle of sticking to
pristine versions of official stable upstream releases except for security
or other vital fixes. (There must be some good reason wxWidgets doesn't
bother to make "subrelease" source tarballs.)
So that _is_ in the fact 2.6.2.1 subrelease. This file appears identical to
the ./include/wx/version.h in the wxPython 2.6.2.1 source tarball.
Grrr... That means that somebody screwed up when the wxGTK release was made and didn't make sure that the subrel number was right. I wasn't around at the time, otherwise I probably would have caught it. I guess I should have looked at the cvs history for version.h and made the wxPython release be 2.6.2.2.
But, a lot of other files _aren't_ the same -- a quick
shows 551 files changed, 28912 insertions(+), 126863 deletions(-). Plus a
diff of the ./include directories shows 327 files changed, 653
insertions(+), 31403 deletions(-).
Yep. There was several months time between the wx 2.6.2 and the wxPython 2.6.2.1, with a large number of bugfixes and minor enhancements.
I see in CVS that there's a "wxPy_2_6_2_1" tag, which is presumably the
point at which your snapshot was taken. But that point doesn't correspond to
the wxWidgets 2.6.2.1 subrelease across all of the source.
Yes it does, or it would if the setting in version.h was correct. The wxGTK 2.6.2 release is tagged with WX_2_6_2, and if you look at the history of version.h you'll see that tag on the version of the file that has wxSUBRELEASE_NUMBER set to 1, which because of the screwup mentioned above is also the revision with the wxPy_2_6_2_1 tag.
BTW, if everybody stays on schedule and there aren't any critical breakages, then there should be a 2.6.3(.0) release in a couple weeks for both wxWidgets and wxPython.
···
On Tue, Feb 07, 2006 at 12:31:14PM -0500, Matthew Miller wrote:
On Tue, Feb 07, 2006 at 09:17:09AM -0800, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Grrr... That means that somebody screwed up when the wxGTK release was
made and didn't make sure that the subrel number was right. I wasn't
around at the time, otherwise I probably would have caught it. I guess
I should have looked at the cvs history for version.h and made the
wxPython release be 2.6.2.2.
Excellent. "It's a screw up" is a much nicer situation than "it's all weird
on purpose".
>I see in CVS that there's a "wxPy_2_6_2_1" tag, which is presumably the
>point at which your snapshot was taken. But that point doesn't correspond
>to the wxWidgets 2.6.2.1 subrelease across all of the source.
Yes it does, or it would if the setting in version.h was correct. The
wxGTK 2.6.2 release is tagged with WX_2_6_2, and if you look at the
history of version.h you'll see that tag on the version of the file that
has wxSUBRELEASE_NUMBER set to 1, which because of the screwup mentioned
above is also the revision with the wxPy_2_6_2_1 tag.
So in general, are the subrelease tags all "wxPy" tags? Are these supposed
to be at least nominally tested and considered stable by wxWidgets.org? I
guess my question here is "Why not wx_2_6_2_1?"
BTW, if everybody stays on schedule and there aren't any critical
breakages, then there should be a 2.6.3(.0) release in a couple weeks
for both wxWidgets and wxPython.
Okay, good -- that should straighten things out. It's a little bit of an
unfortunate timing thing, since it's about time for Fedora Core 5 freeze.
But that's largely my fault since I should have noticed this January 10th or
so.
···
On Tue, Feb 07, 2006 at 12:50:32PM -0800, Robin Dunn wrote:
I see in CVS that there's a "wxPy_2_6_2_1" tag, which is presumably the
point at which your snapshot was taken. But that point doesn't correspond
to the wxWidgets 2.6.2.1 subrelease across all of the source.
Yes it does, or it would if the setting in version.h was correct. The wxGTK 2.6.2 release is tagged with WX_2_6_2, and if you look at the history of version.h you'll see that tag on the version of the file that has wxSUBRELEASE_NUMBER set to 1, which because of the screwup mentioned above is also the revision with the wxPy_2_6_2_1 tag.
So in general, are the subrelease tags all "wxPy" tags?
Usually, although the Debian package maintianer will sometimes make extra subreleases in addition to the existing wxPy tags. (Such as the 2.6.1.2 release.)
Are these supposed
to be at least nominally tested and considered stable by wxWidgets.org?
They are tested by the wxPython-dev group, and some would argue that they are usually more thoroughly tested than what is done by the wxWidgets group because of the automated build stystem we have makes it easy to get test builds out to people. However it is just wxPython that is being tested this way and so some of the non-GUI classes won't get any testing from wxPython-dev. (But so far I don't think that's been a problem.)
I
guess my question here is "Why not wx_2_6_2_1?"
Because wxWidgets folks don't have the same needs that drove us to add the subrelease number, which is the ability to get releases containing bug fixes or enhancements that are critical to wxPython users released and out there. When C++ users need those things the response is usually just something like, "Use the CVS version of foo.cpp." But since the majority of the wxPython users have no idea what a .cpp file is nor how to build it then that's not an option.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Not sure if that's due to a mistake I made or due to some