EditAttachWiki Help
r62 - 07 Feb 2006 - 15:25:15 - LisaDusseaultYou are here: OSAF >  Projects Web  >  DevelopmentHome > WxPythonProject > WxPythonUpdatePlan

Chandler wxPython v2.x Migration Planning

(from v2.5.2 onwards)

(for integrators of new wxPython source releases)

David Surovell

Chandler GUI Frameworks Engineer, OSA Foundation

24 January 2006



Overview

This document tracks the active issues for building wxPython and wxWidgets. This covers changes within OSAF and changes to the open source components upon which they rely. A collection of footprints of older, inactive issues and their resolutions and be found here.

NB: This document is somewhat out of date!

Active Issues, Now

  1. drive adoption of Chandler wxWidgets additions and modifications by wx communities

Active Issues, Sooner

  1. enable wxVersion support - coordinate with Mike and Robin



  2. submitting wxColumnHeader to wxWidgets group
    • write wxWidgets demo application, LaTex documentation



  3. rewrite and submission of WinXP native double-buffering support to wxWidgets community
    • 26-Jul-05 - added canonical wxWidgets compilation flag support
    • need to check 01-Nov-04 list notes
    • write a proposal for generic composited window support
    • address 1-2 problems related to wxMSW implementation of print preview and wxListCtrl



  4. review Robin Dunn's suggestion for undertaking future wxPython integrations via cvs import:
    • no longer practical due to OSAF's switch to SVN



  5. review chandler usage of the following "fragile" wxWidget classes:
    • wxToolbar, wxListCtrl, wxTextCtrl, wxStaticText, wxGrid, wxScrolledWindow



Active Issues, Later

  1. beefing up / chopping up Chandler wxPython Issues page



  2. capture a diff of OSAF and new wxPython versions of "setup.h" (or "setup0.h") and document differences
    • most important for MSW; informative for Mac and GTK builds
    • [v2.6.0] MSW - moved to makefile command line "/D" additions
      • a change that I wish to revert (davids)



  3. revisit the DLL packaging config:
    • the v2.5.2 release required the Mac and GTK targets to be modified:
      • [v2.5.2.x]: core wxWidgets dynamic libs (or DLLs) must be built as a single (monolithic) "wx__.[dylib,dll]" library
      • [v2.5.1.x]: multiple libs
        • core: base, adv, html
        • contrib: gizmos, stc, animate, xrc (now part of core), ogl (obsolete)

wxPython - Update Integration Notes

There are three paths to integrating a new wxPython version. Quick and dirty (QD), clean and proper (CP) or Continuous (Co). The first 2 procedures have several subtasks in common, mostly regarding the re-integration of OSAF widget additions and bug fixes.

The QD path involves renaming the existing "internal/wx", replacing it with the new release, and adding the OSAF stuff back. Pros: quick turnaround, useful for testing a new version fast; Cons: lose CVS continuity, check-in is painful and best, unacceptable at worst. This path is described below in the "Quick and Dirty" section.

The CP path involves doing a careful multi-step file merge from a new release into the existing "internal/wx" directory. Pros: CVS continuity, easy check-in; Cons: easy to lose OSAF stuff, easy to leave crufty files around in CVS. This path is described in the Chandler build wiki page: General Component Update Notes.

The Continuous method is simply to check out from wx CVS, merge update into local "internal/wx", and then check in to OSAF SVN. Pros: quick utilization of wx bug fixes, CVS continuity, easy check-in, no large one-shot task; Cons: lots of ongoing work, more transient build problems.

The common subtasks are described in the next section.

Critical Files To Update

The following files must be diff-merged and edited manually to bring forward OSAF build support into new wxPython builds. At the same time, archaic build constructs must be identified and culled from the change lists.

These files are noted on the Adding wx classes? wiki page:

  • all platforms: makefile.in, wxPython/setup.py
  • all platforms: makefile (for RELVER bump)
  • Mac only: include/mac/carbon/chkconf.h
  • MSW only: build/msw/files.bkl, build/msw/makefile.vc, include/wx/msw/setup.h
  • ../chandler/makefile
    • for RELVER bump when "wxPython-RELVER" tarball has been created and is ready for download



  • NB: all are relative to "internal/wx/"

General v2.x Integration Tasks

The coarse task list is as follows:

  1. enumerate all OSAF wxWidgets(old) changes which will require replication in the wxWidgets(new) installation.



  2. prepare a base of up-to-date, clean Chandler source deployment. This may be updated with subsequent Chandler source changes as the update progresses.



  3. relocate existing wxWidgets(old) subdirectories and files and replace with the corresponding wxWidgets(new) items. Use either the QD or CP plans described above.



  4. all consequent build issues will be addressed, followed by identification and redress of all significant (blocking) execution issues. In particular, update the wxWidgets(new) makefile to function as per the wxWidgets(old).



  5. all changes shall be articulated, compiled and prepared for review:
    • console messages will be fixed, defended or otherwise explained away
    • all required build system and makefile changes must be documented
    • all "chandler" subtree changes should be compiled into a patch and attached to a Bugzilla entry



  6. the resultant Chandler applications will be reviewed by the Applications Development and Build team members, along with the compiled change list and list of known issues and remaining wxWidgets(new) update-related tasks.



  7. all required wxWidgets(old) changes made by the Applications team shall be reviewed and either a) applied to the wxWidgets(new) source, or b) rejected with explanation.



  8. all platform builds released to QA for nominal acceptance testing.



  9. check in the wxWidgets(new) files on CVS branch.



  10. work with QA and fix critical bugs until all 3 platform versions are judged to be acceptably functional.



Quick and Dirty Update Steps

  1. clean out the dirty build directories: refer the "Dirty Directory Manifest" section

  1. copy wxPython(new) distro to "internal/wx":
    • refer to UpdateInternalSources for the CP merge-based methodology
    • rename existing directory to "-old" is fine, don't throw it away just yet



  2. remove the "distutils" subtree from the new directory (if it exists)



  3. copy the following files from "internal/wx-old" to "internal/wx":
    • makefile



  4. edit multi-platform "internal/makefile" as follows:
    • current stuff
    • change WXMAJORVERSIONCOMPACT to "26" (or appropriate version string)
      • for [v2.6.0], no trailing "0"
    • add/subtract build flags in 3 places as appropriate



    • old stuff
    • [v2.5.2] line 39: add "BUILD_ACTIVEX=0"
    • [v2.5.1] line 57, 84: change "--disable-monolithic" to "--enable-monolithic"



  5. copy the following MSW build files and sub-trees from "internal/wx-old" to "internal/wx":
    • include/wx/msw/setup.h
    • build/msw/wx.sln
    • build/msw/wx.vcproj
    • contrib/build/gizmos/wxPythonGizmos/*
    • contrib/build/stc/wxPythonStc/*
    • contrib/build/animate/wxPythonAnimate/* ([v2.6.0]: added)
    • contrib/build/ogl/wxPythonOgl/* ([v2.6.0]: removed)
    • contrib/build/xrc/wxPythonXrc/* ([v2.5.3;1]: migrated to core)



    • NB: add or subtract "contrib/build/(name)/wxPython(name)" subprojects as appropriate and (dis-)connect to/from "build/msw/wx.sln"

  1. edit "include/wx/msw/setup.h" as follows: ([v2.6.0]: moved to makefile command line changes)
    • capture a diff of OSAF and new wxPython versions of this file, reconcile as needed, document OSAF differences
    • [v2.5.2] add "#define wxUSE_MDI 1"



  2. ([v2.5.2] only) edit the following files: (all wxDC coordinate arguments expanded to scalars)
    • application/SimpleCanvas.py
    • parcels/osaf/framework/attributeEditors/AttributeEditors.py
    • parcels/osaf/framework/blocks/calendar/CalendarBlocks.py
    • parcels/osaf/framework/blocks/calendar/CalendarCanvas.py (obsolete?)
    • parcels/osaf/framework/blocks/calendar/CollectionCanvas.py



  3. build everything



  4. run run run - test test test
    • optional: pitch existing "__repository__" by hand if "--create" launch fails



  5. check files in with extreme care
    • give everyone a great deal of warning:
      • coordinate with David, Mike, Robin and possibly Heikki
      • assume that there will be significant CVS issues on check-in
      • assume that reconciliation of build issues on the 2 other platforms will take 8-12 hours
    • when adoption by other team members is accepted, remove dev checkout files, refetch source tree



Chandler wxPython Dirty Directory Manifest

  • NOTE: there is no guaranteed way of getting a successful partial rebuild, check makefiles for sufficient dependencies
    • safest bet: pull a fresh tree and build after penultimate build step (below)
    • 2nd safest bet: pull a fresh external sub-tree
    • On Dev't team Mac laptop, the "external/internal" CVS -> build cycle is about about 3 hours

  1. clean "external/(debug/release)" subtrees:
    • /lib/libwx*
    • /share/wx
    • /include/wx
    • /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx
    • /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wxPython
    • others?



  2. clean "chandler/(debug/release)" subtrees:
    • /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx
    • /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wxPython
    • others?



SWIG - Update Integration Notes

Chandler's SWIG is built from sources in "ROOT/external/SWIG". This directory contains a bunch of SWIG deployment directories, plus patches from Robin Dunn and a "win32" directory created by Robin to update future release of SWIG.

The basic drill:

  1. unpack the new SWIG tarball - should be something like "SWIG-1.3.24"
  2. copy the contents of the "win32" directory over to new "SWIG-(version)" directory
    • edit "win32/sources/include/swigversion.h" for version number updates: "1.3.22" -> (version)
  3. apply the patches
  4. update the "swig/makefile" VERSION variable to "(version)"
  5. run/build the project (on Windows)
    • you may need to add or remove files from "win32/swig13.vcproj"
  6. bump the chandler swig VERSION variable

At this point, all external SWIG client components should be cleaned and rebuilt:

  1. external/PyLucene
  2. external/m2crypto
  3. internal/chandlerdb
  4. internal/wx

After your local build completes, inspect some "*_wrap.cpp" files and verify that the comments show a "built with SWIG (version)" string.

If everything succeeded, then check in the "swig" directory and "chandler/makefile".

Issues History

  • (resolved) m2crypto build has v1.3.24 issues, according to its' keeper
  • (resolved) Robin Dunn deems SWIG v1.3.24 incompatible with wxPython v2.5.3 and below
  • (bear - done) updated external/SWIG as checked in up to v1.3.24 plus Robin's patch
    • are Robin's v1.3.22 dev't notes still relevant to v1.3.24 process? (yes, as of 13 April 2005)

Historical Stuff

Old Upgrade Events

  1. WxPython v2.5.3.1 is now in the Chandler CVS main trunk:
    • active issues
      • some new bugs: Bug#2266 (prob. not v2.5.3.1 related), Bug#2267, Bug#2270
      • some minor CVS cleanup remains
      • SWIG support is integrated and enabled
      • wxVersion support is currently disabled - will enable after requirements review
    • included: David's wxWin WinXP double-buffering fix
    • CVS check-in is "history-friendly"
    • v2.x battle doc has been updated



  2. WxPython v2.5.2.9p4 (091404) is now in the Chandler CVS main trunk:
    • OSAF changes to Robin Dunn release:
      • Jed's wxMac toolbar toggle item fix (accepted in wxPython v2.5.3.x)
      • David's wxMac notebook hit-test addition (accepted in wxPython v2.5.3.x)
      • David's wxWin WinXP double-buffering fix
    • as of 23 September Journal.2004, this task is essentially complete; no blocking bugs



  3. re-introduction of WinXP native double-buffering support

    * as of 16-Sep-04, appears to have fixed Win32 CPU idle problem
    • as of 25-Sep-04, checked in - XP users: please run Task Manager in tray and watch idle clock usage
    • as of 01-Nov-04, have identified 1-2 problems related to wxMSW impl. of print preview and wxListCtrl



  4. determine Chandler changes related to sizer behavior changes imparted by wxPython v2.5.2.x



  5. The following issues were resolved in course of the v2.5.2 update:



    1. review and reimport any OSAF changes to v2.5.1
    2. new wxPython bugs: search Bugzilla for "Wx252x" in the Status Whiteboard field
    3. check in v2.5.2.x sources, preserving version history when possible and appropriate
    4. integrate any wxPython v2.5.2.x changes that are posted after the latest release candidate



    5. integrate appropriate SWIG version into the wxPython v2.5.2.x build process:
      • SWIG has recently been integrated into the Chandler build, but isn't invoked by the internal WxPython build.
        • This means that Chandler-specific wxWidgets API changes cannot be exposed without external interface file generation.
      • the Chandler "external" sub-tree currently has SWIG v1.3.21 + Robin Dunn changes.
      • SWIG v1.3.22 has just been released; v1.3.23 is in development and targeted for a mid-Nov-04 release.
      • SWIG v1.3.23 is likely to be wxPython-compliant without any additional patches, but this isn't certain.
      • (DONE) current plan is for Robin Dunn to visit OSAF and work on integrating v1.3.22 into Chandler build.



    6. prepare for wxPython v2.5.3.x migration changes:
      • change Chandler vcproj hierarchy to account for migration of XRC module from "contrib" into "core"
      • change Chandler manifest file to conform to wxPython's new location inside of "site-packages"



Overview - Background (outdated)

  1. Migrating Chandler to use wxPython v2.5.2 can be subdivided a small number of tasks. These tasks will be replicated across the 3 platforms: Windows XP, MacOS X and and Linux/GTK platform (Fedora Core 2).



  2. see related WxPythonBattleDoc for up-to-date development details.



  3. see related "catch-all" Bug 1472 for current bug status.



  4. The target version of wxPython to integrate is v2.5.2.9p4, posted 14 September Journal.2004 - this is the final v2.5.2.x build. Updates beyond this version will be considered based on analysis of benefits and risk. Robin Dunn has stated that he plans to complete an official v2.5.3.x build: approximate target date of 05-Nov-04.



Using the wxPython v252x Branch (obsolete)

  • Note: the v2529p4 branch has been integrated into the main trunk. The procedure below may be reactivated for future branches.



  1. remove old wxPython files:
    • Windows:
      • rm -fr internal/wx
      • rm -fr external/debug/bin/lib/site-packages/wx*
      • rm -fr external/release/bin/lib/site-packages/wx*
      • rm -fr chandler/debug/bin/lib/site-packages/wx*
      • rm -fr chandler/release/bin/lib/site-packages/wx*
    • Linux, Mac: change paths to your platform (actually, I think it's the same as the other platforms!)



  2. cd internal
    • cvs up -d -r WXPYTHON_2_5_2_9_BRANCH wx
    • cd wx
    • make (DEBUG=1) all snap install



  3. cd ../chandler
  4. at this point, you can continue on your Chandler work
    • check out from main as needed
    • check in to either branch: main and/or 252x
    • I'll merge and verify all chandler checkins to main branch
    • I'll be updating the chandler patch file regularly, as needed
    • please file any new bugs that you encounter, marked with "Wx2529" - thanks!!!
PageInfo
PageType HomePage
MaintainedBy DavidSurovell
PageStatus Source of truth -- this page reflects current OSAF thinking? go.png
Trash.CommentsWelcome2 Feel free to contribute comments?, either by adding to the Comments Welcome section of this page, or by posting to the dev list, or by sending mail directly to the person listed as maintaining the page.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r62 < r61 < r60 < r59 < r58 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.