There is (almost) full support for nsIVariant. Any nsIVariant +parameters will automatically be translated to and from regular Python objects +giving, in effect, a multi-type parameter. This should be automatic, so +there is not much else to say! Note that if you really want, you can +create and pass your own nsIVariant object instead of a regular Python +object, thereby allowing explicit control over the type of variant created.
+There is a set of interfaces described in nsISupportsPrimitives.idl, which I diff --git a/extensions/python/xpcom/doc/configure.html b/extensions/python/xpcom/doc/configure.html index d56f3a5585f0..a4c2dc798db6 100644 --- a/extensions/python/xpcom/doc/configure.html +++ b/extensions/python/xpcom/doc/configure.html @@ -19,14 +19,50 @@ built Mozilla from source and your environment is currently set up for such a build - see the Mozilla build documentation for more information.
-Windows builds now use the standard Mozilla build process. You can +
PyXPCOM can be built on Windows using either the nmake makefile.win +process, or the configure; gmake process used by Linux.
+Windows builds still support the Windows makefile.win build process. You can build them by performing the following steps
+These instructions apply to Linux, and hopefully soon they will die!
-This section covers:
+When you are using PyXPCOM from inside mozilla, no additional configuration +options should be necessary. However, if you wish to use PyXPCOM from +stand-alone Python (ie, so you can write simple Python scripts that can be +executed normally and use XPCOM), then additional environment variables must be +setup.
In addition to the existing environment requirements for building Mozilla itself, the -Python XPCOM package has the following requirements:
--Note that on Windows, the PYTHONPATH is generally maintained in the Registry; however, you can set this variable at a DOS prompt, and it will still be added to the core PYTHONPATH.
The initial release of the Python XPCOM package has a very simple, hard-coded -build process. The intention is to include this package in the Mozilla -source tree, and integrate the build with the Mozilla build. Until this -happens, perform the following steps:
For this example, we will assume that the source-code for Mozilla is in ~/src/mozilla, -the source-code for the PyXPCOM package is in ~/src/pyxpcom. Further, we assume -that you have ActivePython 2.0 installed in /usr/local/ActivePython2.0, -and wish to install the built Python XPCOM package so it exists in /usr/local/ActivePython2.0/lib/python2.0/site-packages/xpcom.
-To build the package in this environment, you would perform the following -steps:
-NOTE: The instructions above are for a Debug build, as this is the default -Mozilla build type. If you have configured Mozilla to build a Release -version of Mozilla, you can drop the DEBUG=1 option. It is important that -PyXPCOM and Mozilla itself are consistent with respect to Release and Debug -builds. For more details, please consult the makefile.
-If everything appears to work and you are brave, you may also like to execute -make -f makefile.stupid.linux test to execute the test script. -Otherwise, continue to the following section where we confirm the installation -step--by-step.
The Python XPCOM Package has a complete test suite. If you are -impatient, you can simply execute make -f makefile.stupid.linux test (for -Linux) or nmake -f makefile.stupid.linux test (for Windows). If -this command indicates that the tests succeeded, then you can ignore the rest of -this section.
+The Python XPCOM Package has a complete test suite.
In the rest of this section, we walk through some simpler tests a step at a time, to help diagnose any problems.
Note: We recommend you do all your testing outside of mozilla.exe; it is far simpler to test all of @@ -136,11 +117,13 @@ this using the PyXPCOM package stand-alone.
If you can't get this going, you won't get much further! If you do, the +
If you can't get this going, you won't get much further! (You may see a few +errors - that is OK, as long as it appears something worked!). If +everything looks OK, the next step is to register our test component and run our full test suite.
First register the generic Python loader. For instructions, see the architecture @@ -162,9 +147,10 @@ finally you can test it!
for Unix), and the files py_test_component.py and py_test_component.idl into the Mozilla bin/components directory. If not, copy the files there manually. -@@ -183,6 +169,11 @@ you do not see these messages the first time you run it, there is the possibility that some other process, possibly the build process, has already executed this step.Running the Test Suite
+Before running the test suite, you should change to the mozilla/xpcom/sample +directory and build it. This will build and install a sample component +which is used by the test suite. If you do not have this component +available, some of the Python tests will fail.
+To run the test suite, run xpcom/test/regrtest.py. This runs the tests and ensures that the test output is as expected. If all tests pass, you have a fully functioning Python XPCOM package. Enjoy!
diff --git a/extensions/python/xpcom/readme.html b/extensions/python/xpcom/readme.html index abb2a445af29..b6cbd20c69e1 100644 --- a/extensions/python/xpcom/readme.html +++ b/extensions/python/xpcom/readme.html @@ -14,7 +14,7 @@Python XPCOM Package
-Mozilla CVS Version - Last updated May 2001
+Mozilla CVS Version - Last updated May 2002
This is the readme for the Python interface to XPCOM.
XPCOM is an acronym for "Cross Platform COM". It has come out of the Mozilla project, which @@ -37,7 +37,7 @@ is, then none of this probably interests you at all!
Note: This package requires Python 1.6 or later; we recommend using the latest -official Python version (currently 2.1). This package works +official Python version. This package works very well with the latest ActivePython, and does not require any external modules or packages beyond what is provided in the core Python release for each platform.
@@ -54,18 +54,6 @@ contributors. "components" directory. This is because we may decide on some smart scheme for recursion (similar to Python packages), and don't want people to rely on simple recursive searches. -No management of the PythonPath is done by the package. You must -arrange for the Python xpcom package to be on your PythonPath. -Significantly, the XPCOM components directory is not on the PythonPath and -generally cannot be, as Python will often find other DLLs in this directory and -attempt to use them as Python modules. This means that Python module -files will not be found in the components directory, even when referenced by -another component - thus, a component can not import another component -source file as a regular module! It is thought that when we know what to -do with sub-directories of the components directory (as described above), some -automated PythonPath support will be provided, so Python components and regular -Python modules the component depends on can exist in the same directory -structure. No unregistration support at all. The main Python Component Loader supports unregistration, but the actual Python objects themselves do not support unregistration. It is unclear if the Component Loader unregistration process needs to manually remove each component it is responsible @@ -91,6 +79,11 @@ documented here just in case! We are still 100% backwards compatible, so usage of QI still works - just is generally not necessary. +Version 0.93 - May 2002
+ +Implement nsIVariant and all new string types. Complete move to +autoconf build system.
+