From WxWiki
Jump to: navigation, search

ORIGINAL submitted SoC proposal

This is the page for one of the Google SoC projects 2006; see Development:_Student_Projects for more info. Here is a copy of the ORIGINAL project submitted info (see following sections for current design status):

Name: Francesco Montorsi

E-mail Address: f18m_cpp217828@!NOSPAM!

Project Title: wxWidgets components package manager

Project Goals: the goals of this project would be to have a cross-platform application which makes easy for developers to download, compile and install wxWidgets-based libraries (also referred as components or packages)

Project Benefits: This project will make it easier for developers to handle 3rd party dependencies in their projects and make the development environment setup much more fast.

Project Tasks and Deliverables: The project would be divided in

  • defining with the help of wx developers (and maybe the entire wx community) exactly an easy-to-learn XML package descriptor for wxWidgets packages
  • create a GUI program which
    • downloads list of wx extensions available from some fixed site
    • download user-chosen source packages from net using info in the wxextensions list
    • build the package (using makefiles created by the package maintainer through e.g. a bakefile)
    • install it in wxWidgets folder to make it 'integrated' with wx and making it easier to use the components (i.e. no additional header/lib search paths to give to the compiler)
  • test accurately the program on different platforms and create a wizard for importing or creating new wxWidgets packages
  • create a new sample in wxWidgets tree which shows how to prepare such type of packages
  • predisposition of the wxCode website for use of the new package manager

Project Schedule: project setup and step 1 will take about 1-2 weeks; step 2a will take 2 weeks; step 2b depends in particular from the state of wxNet library (it could be required to use a 3rd party library for handling e.g. multithreaded downloads, etc) - expect 2 weeks. steps 2c+2d will take 1 week; step 3 will take 2 weeks. Step 4 and 5 should be simple enough to take 1 week. Remaining time will be dedicated to testing of the component manager.

Current project schedule

  • before June 30: complete the wxPM GUI making it fully working.
  • before July 11: complete the wxP GUI making it fully working.
  • before July 30: write the WXP library and complete GUI testing.
  • before August 15: fix all remaining problems, check status of CMake and Scons support.
  • before August 21: complete WXP-ification of some of the wxCode components.

Detailed design

Parts highlighted like this are those which I think need more discussion.

Package Manager file format and other standards

A wxWidgets package description file has extension WXP.

The purposes of the WXP file include:

  • Giving a human-readable description of the package.
  • Telling the package manager where to find the latest package and how to download it.
  • Telling the package manager how to unpack, compile, install the package.

So, the WXP file may be downloaded as part of the actual package, or it may simply say where to get the package.

A central index of packages may consist of the WXP files, but not the actual packages themselves. Actually, to increase package manager performances over remote repositories of packages, a WXL file will be loaded by the package manager: such file is a simple XML file (like WXP are) which contains all repositories' WXP files. This allows the PM to download a single file and have all info about all packages at once.

The PM also saves in wxConfig all infos that describe locally installed packages.

Package description files may be compiled along with the package content into a compressed (ZIP as wxWidgets supports them out-of-the-box) WXZ file.

So that tools know where to find them, WXP files and downloaded packages are stored locally in a standard location. For example:

  • c:\ Documents and Settings\Julian Smart\wxWidgets Packages\ledctrl\ledctrl.1.2.3.wxp
  • c:\ Documents and Settings\Julian Smart\wxWidgets Packages\ledctrl\ledctrl.1.2.4.wxp

The build method used for compiling a package is up to the package distributor, and the WXP file is flexible enough to cope with this variety by allowing the specification of scripts. However, there is a small number of standards such as bakefile which the package manager can handle in a more satisfactory way than arbitrary methods.

Creating a sigle WXZ file containing multiple packages and a WXL file zipped together with them allows the packager to create a package which looks like many independent packages once decompressed.

The WXP file contains information including the following:

  • Basics
    • Name: string
    • Version: string in form A.B.C (if we allow non standard version strings how can we do checks like those needed for dependency-resolution and for update checks ?)
    • Description: string MULTILINE - can be long as packager wants (but the GUI could truncate it)
    • Keywords: string (list) - can be freely chosen by the packager
    • Primary Category: choice among fixed list of options
    • Secondary Category: choice among fixed list of options
    • Package web site: string
    • Package creation date: string
  • Licensing
    • License: string (should we allow multiple licenses? I think we should but then how do we spceify which applies when ?) + href
    • License type: string
    • Organisation: string
    • Organisation web site: string
    • Cost: string or url for more detailed pricing.
    • Authors: name + href
    • Maintainer: name + href
    • Credits: string
    • Copyright: string
  • Details
    • Build system: bakefile|cmake|scons|makefile etc
    • Status: alpha|beta|stable
    • Programming language: C++, Python, ...
    • Package RSS feed: url
    • Component download locations: url (list)
    • Package documentation: url (list) - can be referred to the package itself (e.g. file:///docs/docs.htb) or a remote url
    • Screenshots: urls (comma-separated) - can be referred to the package itself (e.g. file:///images/im.png) or a remote url
    • Number of samples provided
  • Dependencies
    • Supported wxWidgets versions: string, e.g. 2.4-2.5.4 (can be a range if '-' is used, or a number with optional wildcard 'x': 2.6.x)
    • Supported wxWidgets ports: multiple choice among ANY|wxGTK|wxMSW|wxOS2|wxMAC|etc
    • Tested wxWidgets ports: multiple choice among ANY|wxGTK|wxMSW|wxOS2|wxMAC|etc
      • Package dependencies:
        • Type: Required|Suggested|RequiredButNotPackaged
        • ID of the package required (name+version)
        • URL: where the package (WXZ or WXP) can be found

Common stuff for all stages:

  • BAKEFILE and MAKEFILE build systems only:
    • set of options, each of them is characterized by the following informations:
      • Name: string, e.g. BUILD, UNICODE or SHARED
      • Possible values: list of comma-separed strings; e.g. "1,0" or "on,off"
      • Description: string, e.g. "Compile in debug mode ?"
      • Default value: string
      • Stage to which it applies to: build|install|uninstall
      • Category of the option: string, e.g. "compiler" or "wxWidgets"
    • available targets for this stage: list of comma-separed strings; e.g. "all,samples,lib"
  • Build
    • Type: multiple choice among static library|dynamic library|executable
    • Compile commands
      • Linux gcc: string. E.g. cd %INSTALLDIR%/%BUILDDIR%; configure; make
      • VC++: string. E.g. cd %INSTALLDIR%/src; make %WXMAKEOPTIONS%

  • Install
    • Install commands
      • Linux gcc: string. E.g. make install %DESTDIR%
      • VC++: string. E.g. make install %DESTDIR%

  • Uninstall
    • Uninstall commands
      • Linux gcc: string. E.g. make uninstall %DESTDIR%
      • VC++: string. E.g. make uninstall %DESTDIR%

An example of the XML format is in the development section of this page (see below).

Package Manager GUI

The GUI contains a wxNotebook with following tabs: Summary, Details, Reference, and Browser.

The Summary tab contains the HTML package description, including any images in the specification, is displayed on the right hand side; The Details tab is pretty much the same with more info.

The Reference tab shows the wxWidgets reference manual and potentially the Packager Guide and the guide of the package itself.

The Browser tab contains a full web browser (on supported platforms) and can be used to browse the web site associated with a package.

Package management capabilities of the GUI tool

From the tool, the user can do the following.

  • Browse available packages locally
  • Download a list of available packages from selected servers.
  • View details and browse associated web sites.
  • Download, install and compile packages.
  • Uninstall packages.
  • View currently installed packages and their available configurations and dependencies.
  • Browse the files in a package (such as source files or documentation), where specified. When available in a compatible format (e.g. HTB), a package’s documentation is integrated into the tool for easy access.
  • Create new packages and edit existing ones.

Futher ideas

Time-permitting these are some additional ideas for the PM:

  • RSS news reader embedded in PM
  • command-line package compiler so that it's possible to integrate the packaging in build systems of the components
  • small set of PHP functions to layout WXP informations in webpages
  • add concept of 'component' inside a package (questions about this: would they be just 'subpackages', and this would just be a way to pack many packages in a single file or rather they would indicate sub parts of the same package ? In this last case we must ask: is it necessary ? Why a package should be split in different parts from PM's POV ?). Adding WXL format (which actually implements the 'subpackages' approach) this is probably unnecessary.
  • support for 'commercial' packages: i.e. packages which do not distribute sources at all but just DLLs (NOTE: for final EXEs another package format should be used - WXP are targeted for developers; if you want to target *users* then you should choose MSI, RPM or whatever is designed to handle the binary hell).
  • Upload packages and their descriptions.


The development of the wxWidgets Package Manager (wxWPM) now takes place in the CVS repo of the wxWPM project. For more info about on-going project please look at