[wxPython] More feedback questions

[Matthew_Thornley]

RE: [wxPython] More feedback questions

From: Robin Dunn

3. Compile options: I’m thinking about dropping the -hybrid builds (and

also the -dbg RPM I just announced) and instead do a single build that is

something in between the FINAL and HYBRID that I’ve done in the past.

Specifically it will be like the FINAL in that compiler optimizations will

be turned on and debugging info won’t be generated, but

WXDEBUG will be

turned on so that the various runtime checks will always be

there. As it is

now it takes me a complete a day to do all the builds and to do test

installs, much longer if I have to make changes to installers, etc. I’d

like to chop that in half if possible.

For me, the most useful aspect of the Hybrid build was the memory leak report. Would it be possible to make it a runtime option somehow… maybe using an environment variable? Or would that be too much of an impact on speed and/or memory? If so, how about leaving the memory leak report in as a build option? At least we would be able to build it ourselves.

Thanks for including the build for python 2.1. Builds for 2.1 and 2.2 are plenty for me.

Matthew

···

-----Original Message-----

From: Robin Dunn [mailto:robin@alldunn.com]

Sent: Friday, July 19, 2002 6:55 PM

To: wxPython-users; wxpython-mac@lists.wxwindows.org

Subject: [wxPython] More feedback questions

Hi again.

While thinking about the upcoming 2.3.3 release I have come up with some

more things that I would like to get feedback from the community on.

1. Package/Installer naming: I’m going to standardize a bit and change the

names of the installers and packages (as in RPMs and .dmg’s, not Python

packages) and use the name of the wx port in the name. For example:

wxPythonMSW, wxPythonGTK, etc. Hopefully someday there will be a

wxPythonX11… I’m not sure though what to do about the Mac OSX version.

There are in effect several wx ports that run on the Mac, Classic, Carbon,

and an OSX-only version built using the Apple Developer Tools. Currently

wxPython only works with the latter one. So should it be wxPythonMac,

wxPythonOSX, wxPythonMacOSX, wxPythonMacho, or ???

2. Python versions: I plan on doing binary builds for both Python 2.1 and

2.2, (except on the Mac where it will only be 2.2.) Is this enough? If

not, why not?

3. Compile options: I’m thinking about dropping the -hybrid builds (and

also the -dbg RPM I just announced) and instead do a single build that is

something in between the FINAL and HYBRID that I’ve done in the past.

Specifically it will be like the FINAL in that compiler optimizations will

be turned on and debugging info won’t be generated, but WXDEBUG will be

turned on so that the various runtime checks will always be there. As it is

now it takes me a complete a day to do all the builds and to do test

installs, much longer if I have to make changes to installers, etc. I’d

like to chop that in half if possible.

That’s all for now.

–

Robin Dunn

Software Craftsman

http://wxPython.org Java give you jitters? Relax with wxPython!

[Mike_C_Fletcher2]

One note: installed base of Python 1.5.2 for Linux (Red Hat in particular) is probably one of the largest at the moment.

Have you (Robin) considered following a "packager" model? That is, you compile the 2.2 RPM binary (or even don't, just confirm it builds), others contribute back binary builds for 1.5.2, 2.0, and 2.1, with still others doing the .deb packages, the .ppm packages, the missing win32 installers, etceteras. I'm sure there are lots of users who have compilers and might be willing to step up to do the compilation (esp. for *nix boxes).

The security issues are notable, users of the binary builds are basically trusting that the packager is trustworthy (won't introduce nasty code), and conscientious (doesn't have an infected/compromised machine). This would likely require that you set up a seperate section on the web-site for "contributed builds", and/or mark the builds as not originating from you (Robin). Possibly include "unofficial" in the binary package name (not sure if that would mess up certain package schemes though (hopefully not)).

Similarly, full-Hybrid (or whatever we're calling the one with memory-leak+assert support) and/or full-Debug builds could be something contributed after release by a packager. Would suggest that each packager maintain a certain set of builds, rather than just having "whoever" do it each time (for auditability, it's better to have a single "Python 1.5.2 Linux RPM packager" so you know all the RPMs come from them, and if you went through the work of trusting the packager once, you may as well continue trusting them).

With such a scheme, I'd think this would be the minimum release set from you (Robin) for a final version:
  Python 2.2 [.exe, bin.rpm, src[.zip,.tgz], bin.OSX]
  Python 2.1 [.exe, bin.rpm, src.zip]

Just a thought,
Mike

Matthew Thornley wrote:
...

Thanks for including the build for python 2.1. Builds for 2.1 and 2.2 are plenty for me.

...

<Somewhere in there Robin wrote>

2. Python versions: I plan on doing binary builds for both Python 2.1 and
2.2, (except on the Mac where it will only be 2.2.) Is this enough? If
not, why not?

...