I would like to help development where I can. Should I put my svn
wxPython trunk directory inside my wxWidgets trunk directory or does
it matter?
Thanks,
-Tom
Thomas M. Browder, Jr.
Niceville, Florida
USA
I have mine side-by-side, but it shouldn't matter. IIRC, if WXWIN is not set in the environment then setup.py will check both .. and ../wxWidgets.
···
On 7/30/10 11:41 AM, Tom Browder wrote:
I would like to help development where I can. Should I put my svn
wxPython trunk directory inside my wxWidgets trunk directory or does
it matter?
--
Robin Dunn
Software Craftsman
I am working on the wxPython trunk using python 3.1 and the wxWidgets trunk.
I have successfully compiled wxWidgets.
I am now starting on wxPython by working through updating the
build-wxpython.py file.
Am I wasting my time or working cross-purposes with anyone? Or should
I be working elsewhere.
Regards,
-Tom
Thomas M. Browder, Jr.
Niceville, Florida
USA
···
On Fri, Jul 30, 2010 at 14:21, Robin Dunn <robin@alldunn.com> wrote:
On 7/30/10 11:41 AM, Tom Browder wrote:
I would like to help development where I can. Should I put my svn
Hi Tom,
I would like to help development where I can. Should I put my svn
I am working on the wxPython trunk using python 3.1 and the wxWidgets trunk.
I have successfully compiled wxWidgets.
I am now starting on wxPython by working through updating the
build-wxpython.py file.Am I wasting my time or working cross-purposes with anyone? Or should
I be working elsewhere.
I don't think you're working cross-purposes with anyone, but working on Python 3 bindings will most likely require some creative problem-solving, which is the main reason such bindings don't already exist. The first, most pressing problem is that the version of SWIG we use to generate the bindings is not Python 3 compatible, but we use a modified SWIG so a more modern, stock SWIG probably won't work with the wxPython .i files, and it's hard to say if the SWIG patches will simply apply to a modern SWIG build. That being said, perhaps it will Just Work, so that's one way to approach the problem.
To add to that, the Python 3 bindings issue kind of dovetails with a couple other projects we've been wanting to pursue in order to greatly reduce the amount of wxPython maintenance effort needed, which are automated generation of the bindings and the docs based on the XML output generated by Doxygen. I think this would allow us to use a stock SWIG (as IIRC most of the wxPy extensions to SWIG are for docstrings), and maybe even better, allow us to seriously investigate alternatives like SIP, which in some basic tests can provide up to a 50% speedup on load and greatly reduce memory usage.
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or SIP bindings. The main thing that's left to figure out is the mechanism by which we add manual tweaks to the bindings, like, for example, things to be excluded, aliases for members, or things like adding a notation for things like object ownership when a C++ wx object will take over management of a wxPython object. (or vice-versa)
Regards,
Kevin
···
On Aug 21, 2010, at 10:18 AM, Tom Browder wrote:
On Fri, Jul 30, 2010 at 14:21, Robin Dunn <robin@alldunn.com> wrote:
On 7/30/10 11:41 AM, Tom Browder wrote:
Regards,
-Tom
Thomas M. Browder, Jr.
Niceville, Florida
USA--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
Hi Tom,
Hi, Kevin
I have successfully compiled wxWidgets.
I am now starting on wxPython by working through updating the
build-wxpython.py file.
I started there because I jumped right into the build process as a
natural starting point, so maybe finishing that script would not be
wasted effort (but see next para.)
Also, while working on build-wxpython.py I discovered that it has
dependencies on Python scripts in the WxWidgets trunk, so I have to go
back there to fix that one first.
Thus maybe my current rabbit hole is not the place to go for now!
...
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or
Should I try to contribute there then?
-Tom
···
On Sat, Aug 21, 2010 at 14:29, Kevin Ollivier <kevino@theolliviers.com> wrote:
Hi Tom,
Hi Tom,
Hi, Kevin
I have successfully compiled wxWidgets.
I am now starting on wxPython by working through updating the
build-wxpython.py file.I started there because I jumped right into the build process as a
natural starting point, so maybe finishing that script would not be
wasted effort (but see next para.)Also, while working on build-wxpython.py I discovered that it has
dependencies on Python scripts in the WxWidgets trunk, so I have to go
back there to fix that one first.
Yes, in wx trunk, build-wxpython.py configures and builds wxWidgets itself using some wxWidgets build scripts. This was done to remove a lot of the manual process found in BUILD.html for the 2.8 series of releases.
In trunk, to build wxPython (of course, for python 2.x) all you should need to do is make sure your wxWidgets and wxPython checkouts are either in the same parent directory or that your wxPython checkout is inside your wxWidgets checkout root dir. Either way should work fine. Then run build-wxpython.py, get some coffee, and come back to play with wxPython when it's done. 
Thus maybe my current rabbit hole is not the place to go for now!
I would make sure that build-wxpython.py works fine up until the point that you're building the SWIG bindings. The script should give you a properly configured, wxPython-compatible wx build. What you might want to do too, if you haven't already, is make sure you can get a working Python 2.x build going first, just to make sure your build environment is set up properly.
...
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or
Should I try to contribute there then?
Any help would certainly be welcomed! Please post any problems you run into or questions here!
Thanks,
Kevin
···
On Aug 21, 2010, at 12:43 PM, Tom Browder wrote:
On Sat, Aug 21, 2010 at 14:29, Kevin Ollivier <kevino@theolliviers.com> wrote:
-Tom
--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
To add to that, the Python 3 bindings issue kind of dovetails with a couple other projects we've been wanting to pursue in order to greatly reduce the amount of wxPython maintenance effort needed, which are automated generation of the bindings and the docs based on the XML output generated by Doxygen. I think this would allow us to use a stock SWIG (as IIRC most of the wxPy extensions to SWIG are for docstrings), and maybe even better, allow us to seriously investigate alternatives like SIP, which in some basic tests can provide up to a 50% speedup on load and greatly reduce memory usage.
I'm using a modified version of the doxy2swig script [1] which can parse the doxygen xml output and convert it into swig %feature("docstring") lines. You can probably do more stuff advanced stuff with it if you really want to. From my experience the doxygen C++ parser is not better than SWIG's C++ parser though (for actual code, not comments).
What's your main motivation to switch to SIP? It seems to be lacking several things, e.g. template support.
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or SIP bindings. The main thing that's left to figure out is the mechanism by which we add manual tweaks to the bindings, like, for example, things to be excluded, aliases for members, or things like adding a notation for things like object ownership when a C++ wx object will take over management of a wxPython object. (or vice-versa)
Does this approach save you a lot of time maintaining wxPython? I'm just curious, because I've got a project which uses SWIG heavily, too. Most of the time I spent on customizing the wrappers so they are more "pythonic". Right now I can't see how to do this in an automatic way.
-Matthias
[1] http://svn.tuebingen.mpg.de/shogun/trunk/src/.doxy2swig.py
···
Am 21.08.2010, 21:29 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:
Hi Matthias,
To add to that, the Python 3 bindings issue kind of dovetails with a couple other projects we've been wanting to pursue in order to greatly reduce the amount of wxPython maintenance effort needed, which are automated generation of the bindings and the docs based on the XML output generated by Doxygen. I think this would allow us to use a stock SWIG (as IIRC most of the wxPy extensions to SWIG are for docstrings), and maybe even better, allow us to seriously investigate alternatives like SIP, which in some basic tests can provide up to a 50% speedup on load and greatly reduce memory usage.
I'm using a modified version of the doxy2swig script [1] which can parse the doxygen xml output and convert it into swig %feature("docstring") lines. You can probably do more stuff advanced stuff with it if you really want to. From my experience the doxygen C++ parser is not better than SWIG's C++ parser though (for actual code, not comments).
Yeah, we can probably use this as at least a start on migrating the docstring support out of the bindings, and hopefully also getting some Sphinx docs going.
What's your main motivation to switch to SIP? It seems to be lacking several things, e.g. template support.
Aside from the aforementioned 50% speedup on load and greatly reduced memory usage? Memory usage and load times are probably the primary areas in which wxPython apps do not compare favorably to other native apps. As I said, we'd like to investigate a switch. Maybe the real-world benefits wouldn't pan out so well, or maybe they would. There may be holdups but I suspect we can get things working. Having automated bindings generation means we can investigate switching to any tool fairly easily. When you look at docs/doxygen/scripts/swig_tools.py and sip_tools.py, you can see that adding support for a new bindings tool is not going to take weeks or months to put together. It becomes almost trivial, and at that point, why not do some testing to find out which tool is best suited for the job?
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or SIP bindings. The main thing that's left to figure out is the mechanism by which we add manual tweaks to the bindings, like, for example, things to be excluded, aliases for members, or things like adding a notation for things like object ownership when a C++ wx object will take over management of a wxPython object. (or vice-versa)
Does this approach save you a lot of time maintaining wxPython? I'm just curious, because I've got a project which uses SWIG heavily, too. Most of the time I spent on customizing the wrappers so they are more "pythonic". Right now I can't see how to do this in an automatic way.
Well, first off, the wrappers need updated manually (which pretty much is always done by Robin himself) any time a new method or class is introduced. This alone happens often enough that wxPython trunk generally only builds against whatever specific revision of wx Robin last tested with. With automated bindings, that would be largely unnecessary. You could probably pull almost any revision of wxWidgets trunk, pull the latest wxPython, and just build it.
As for making the wrappers more "pythonic", aside from the fact that I feel that's a fairly nebulous term, I'm actually curious about what part of that couldn't be automated. The only things I can think of off-hand that require manual tweaking would be object ownership issues (e.g. the pointer returned by this method changes ownership to the caller). And even there if we added a Doxygen macro to indicate when ownership transfer took place (would be good to know for C++ users too!) we could probably automate that too.
Property support can be auto-generated, method names can have their cases shifted as per any Python PEP naming guidelines you wish to follow, of course wxWhatever can be made into wx.Whatever, you can have the script replace a wx.Whatever type argument with Python types like tuples in the docs, etc. The other manual issue we need to deal with regarding SWIG is method aliases because SWIG can't handle the same method with multiple keyword forms, but I think other bindings tools like SIP can handle that.
Regards,
Kevin
···
On Aug 21, 2010, at 1:20 PM, Matthias wrote:
Am 21.08.2010, 21:29 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:
-Matthias
[1] http://svn.tuebingen.mpg.de/shogun/trunk/src/.doxy2swig.py
--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
...
I would make sure that build-wxpython.py works fine up until the point that you're building the SWIG bindings. The script should give you a properly configured, wxPython-compatible wx build.
Okay.
What you might want to do too, if you haven't already, is make sure you can get a working Python 2.x build going first, just to make sure your build environment is set up properly.
Good idea, I had success with Python 2.7 but only with the latest 2.8
wxPython package.
Thanks,
-Tom
···
On Sat, Aug 21, 2010 at 15:02, Kevin Ollivier <kevino@theolliviers.com> wrote:
Hm, do I understand that I should have a clean wxWidgets source tree
before I start the build script? And it builds wxWidgets and wxPython?
-Tom
···
On Sat, Aug 21, 2010 at 15:02, Kevin Ollivier <kevino@theolliviers.com> wrote:
Yes, in wx trunk, build-wxpython.py configures and builds wxWidgets itself using some wxWidgets build scripts. This was done to remove a lot of the manual process found in BUILD.html for the 2.8 series of releases.
I'm using a modified version of the doxy2swig script [1] which can parse the doxygen xml output and convert it into swig %feature("docstring") lines. You can probably do more stuff advanced stuff with it if you really want to. From my experience the doxygen C++ parser is not better than SWIG's C++ parser though (for actual code, not comments).
Yeah, we can probably use this as at least a start on migrating the docstring support out of the bindings, and hopefully also getting some Sphinx docs going.
My version of the script has some modifications that translate some of the doxygen stuff to sphinx style. It's specific to my project, but I can send it to you if you want it.
What's your main motivation to switch to SIP? It seems to be lacking several things, e.g. template support.
Aside from the aforementioned 50% speedup on load and greatly reduced memory usage?
Doing "python" takes longer then "import wx" on my machine. In total it's about 3 seconds which I am really happy with. Memory is not a problem for me either. But everybody's mileage varies I guess. Also reduced memory footprint is probably interesting if you want to port wxPython to mobile platforms.
As I said, we'd like to investigate a switch. Maybe the real-world benefits wouldn't pan out so well, or maybe they would. There may be holdups but I suspect we can get things working. Having automated bindings generation means we can investigate switching to any tool fairly easily. When you look at docs/doxygen/scripts/swig_tools.py and sip_tools.py, you can see that adding support for a new bindings tool is not going to take weeks or months to put together. It becomes almost trivial, and at that point, why not do some testing to find out which tool is best suited for the job?
That's certainly a healthy approach. For my own needs I think I can't abstract it easily like this, there are too many custom things like smart pointer typemaps etc.
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or SIP bindings. The main thing that's left to figure out is the mechanism by which we add manual tweaks to the bindings, like, for example, things to be excluded, aliases for members, or things like adding a notation for things like object ownership when a C++ wx object will take over management of a wxPython object. (or vice-versa)
Does this approach save you a lot of time maintaining wxPython? I'm just curious, because I've got a project which uses SWIG heavily, too. Most of the time I spent on customizing the wrappers so they are more "pythonic". Right now I can't see how to do this in an automatic way.
Well, first off, the wrappers need updated manually (which pretty much is always done by Robin himself) any time a new method or class is introduced. This alone happens often enough that wxPython trunk generally only builds against whatever specific revision of wx Robin last tested with. With automated bindings, that would be largely unnecessary. You could probably pull almost any revision of wxWidgets trunk, pull the latest wxPython, and just build it.
As for making the wrappers more "pythonic", aside from the fact that I feel that's a fairly nebulous term, I'm actually curious about what part of that couldn't be automated. The only things I can think of off-hand that require manual tweaking would be object ownership issues (e.g. the pointer returned by this method changes ownership to the caller). And even there if we added a Doxygen macro to indicate when ownership transfer took place (would be good to know for C++ users too!) we could probably automate that too.
Yeah, you might be right. If you introduce some kind of "annotation language" which you can process and then generate swig/sip output from, it might just work. I think for my own project it would not be worth the hassle though. There are many things like smart pointer typemaps, operator typemaps, string typemaps, point <-> sequence conversion and other stuff which need swig-specific typemaps atm. When adding new stuff I can usually just %include it. Since wxWidgets is not hardcore C++ though I guess it might turn out much simpler.
Property support can be auto-generated,
I have a script which does this at import time. You can hand it a module or class and it will autogenerate the properties from Get/Set/Is methods. If you are interested, I can send it to you as well. The downside of doing this at import time is that the properties don't appear in the code. Sphinx still gets it right though since it does inspection at runtime.
method names can have their cases shifted as per any Python PEP naming guidelines you wish to follow, of course wxWhatever can be made into wx.Whatever, you can have the script replace a wx.Whatever type argument with Python types like tuples in the docs, etc.
Yes, that's certainly nice to have.
The other manual issue we need to deal with regarding SWIG is method aliases because SWIG can't handle the same method with multiple keyword forms,
Can you give an example of multiple keyword forms?
Finally, creating a "meta-wrapper" sounds interesting. SWIG certainly has its shortcomings like not being able to transform the input in an arbitrary way before generating the output. There were a handful of discussions in the past which would have allowed one to do anything you mentioned. Swig would parse the code, generate an XML tree, you could run an arbitrary transformations on it (possibly defined in python) and finally output the code you want. That's very similar to your proposal. You could probably even go a step further later and replace the swig/sip backends with your own wrapper code generator optimized towards your needs (like increased runtime performance or decreased runtime memory consumption).
If your prototype turns out well, I might look into this again. It looks like a good starting point to replace SWIG (for python wrapping at least). Real development of SWIG has somewhat stalled and it's not moving anywhere during the last years 
-Matthias
···
Am 21.08.2010, 22:49 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:
Hi Tom,
Yes, in wx trunk, build-wxpython.py configures and builds wxWidgets itself using some wxWidgets build scripts. This was done to remove a lot of the manual process found in BUILD.html for the 2.8 series of releases.
Hm, do I understand that I should have a clean wxWidgets source tree
before I start the build script? And it builds wxWidgets and wxPython?
It doesn't need to be clean, but yes, it should build both wxWidgets and wxPython. Are you hitting an issue somewhere?
Regards,
Kevin
···
On Aug 22, 2010, at 5:21 AM, Tom Browder wrote:
On Sat, Aug 21, 2010 at 15:02, Kevin Ollivier <kevino@theolliviers.com> wrote:
-Tom
--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
Hi Matthias,
I'm using a modified version of the doxy2swig script [1] which can parse the doxygen xml output and convert it into swig %feature("docstring") lines. You can probably do more stuff advanced stuff with it if you really want to. From my experience the doxygen C++ parser is not better than SWIG's C++ parser though (for actual code, not comments).
Yeah, we can probably use this as at least a start on migrating the docstring support out of the bindings, and hopefully also getting some Sphinx docs going.
My version of the script has some modifications that translate some of the doxygen stuff to sphinx style. It's specific to my project, but I can send it to you if you want it.
Certainly, if you wouldn't mind.
What's your main motivation to switch to SIP? It seems to be lacking several things, e.g. template support.
Aside from the aforementioned 50% speedup on load and greatly reduced memory usage?
Doing "python" takes longer then "import wx" on my machine. In total it's about 3 seconds which I am really happy with. Memory is not a problem for me either. But everybody's mileage varies I guess. Also reduced memory footprint is probably interesting if you want to port wxPython to mobile platforms.
Speed is definitely dependent on the machine and context (though on my Mac, importing wx is definitely slower than starting Python), but yes, the bigger concern is memory usage. I have seen the memory climb to way higher than it should be because of SWIG on some larger apps, and I've seen wxPython apps pretty much climb to the very top of the app list on the activity monitor. Not a deal breaker for many apps, but if we can decrease those things it will certainly make for an even more awesome toolkit.
As I said, we'd like to investigate a switch. Maybe the real-world benefits wouldn't pan out so well, or maybe they would. There may be holdups but I suspect we can get things working. Having automated bindings generation means we can investigate switching to any tool fairly easily. When you look at docs/doxygen/scripts/swig_tools.py and sip_tools.py, you can see that adding support for a new bindings tool is not going to take weeks or months to put together. It becomes almost trivial, and at that point, why not do some testing to find out which tool is best suited for the job?
That's certainly a healthy approach. For my own needs I think I can't abstract it easily like this, there are too many custom things like smart pointer typemaps etc.
The work that's been done so far towards this is available in the wxWidgets tree in the docs/doxygen/scripts folder. Once you run `docs/doxygen/regen.sh xml` you can run the scripts in docs/doxygen/scripts to generate either SWIG or SIP bindings. The main thing that's left to figure out is the mechanism by which we add manual tweaks to the bindings, like, for example, things to be excluded, aliases for members, or things like adding a notation for things like object ownership when a C++ wx object will take over management of a wxPython object. (or vice-versa)
Does this approach save you a lot of time maintaining wxPython? I'm just curious, because I've got a project which uses SWIG heavily, too. Most of the time I spent on customizing the wrappers so they are more "pythonic". Right now I can't see how to do this in an automatic way.
Well, first off, the wrappers need updated manually (which pretty much is always done by Robin himself) any time a new method or class is introduced. This alone happens often enough that wxPython trunk generally only builds against whatever specific revision of wx Robin last tested with. With automated bindings, that would be largely unnecessary. You could probably pull almost any revision of wxWidgets trunk, pull the latest wxPython, and just build it.
As for making the wrappers more "pythonic", aside from the fact that I feel that's a fairly nebulous term, I'm actually curious about what part of that couldn't be automated. The only things I can think of off-hand that require manual tweaking would be object ownership issues (e.g. the pointer returned by this method changes ownership to the caller). And even there if we added a Doxygen macro to indicate when ownership transfer took place (would be good to know for C++ users too!) we could probably automate that too.
Yeah, you might be right. If you introduce some kind of "annotation language" which you can process and then generate swig/sip output from, it might just work. I think for my own project it would not be worth the hassle though. There are many things like smart pointer typemaps, operator typemaps, string typemaps, point <-> sequence conversion and other stuff which need swig-specific typemaps atm. When adding new stuff I can usually just %include it. Since wxWidgets is not hardcore C++ though I guess it might turn out much simpler.
Actually, typemaps are the other (obvious) case that can't be automated, which I'm surprised I forgot since I had to write some for wxWebKit just a few days ago. 
However, at least in the case of SWIG, we have typemaps done already, so it'd just be a matter of collecting them and throwing them into a file and maintaining that file IIUC.
Property support can be auto-generated,
I have a script which does this at import time. You can hand it a module or class and it will autogenerate the properties from Get/Set/Is methods. If you are interested, I can send it to you as well. The downside of doing this at import time is that the properties don't appear in the code. Sphinx still gets it right though since it does inspection at runtime.
Thanks, though adding build time support for property generation to the scripts won't be any hassle. I think wxPython used to have similar code in it before Robin switched to the build time approach.
method names can have their cases shifted as per any Python PEP naming guidelines you wish to follow, of course wxWhatever can be made into wx.Whatever, you can have the script replace a wx.Whatever type argument with Python types like tuples in the docs, etc.
Yes, that's certainly nice to have.
The other manual issue we need to deal with regarding SWIG is method aliases because SWIG can't handle the same method with multiple keyword forms,
Can you give an example of multiple keyword forms?
Multiple keyword forms might not be the right term, but in any case, multiple constructors are the case that immediately comes to mind. (e.g. In wxPython, we have wx.Bitmap, wx.BitmapFromImage, etc. to handle the various constructors) There are other examples in the API, but they escape me off-hand. It's possible SWIG may have added this support in a later release and we don't use it since we need a custom SWIG.
Finally, creating a "meta-wrapper" sounds interesting. SWIG certainly has its shortcomings like not being able to transform the input in an arbitrary way before generating the output. There were a handful of discussions in the past which would have allowed one to do anything you mentioned. Swig would parse the code, generate an XML tree, you could run an arbitrary transformations on it (possibly defined in python) and finally output the code you want. That's very similar to your proposal. You could probably even go a step further later and replace the swig/sip backends with your own wrapper code generator optimized towards your needs (like increased runtime performance or decreased runtime memory consumption).
If your prototype turns out well, I might look into this again. It looks like a good starting point to replace SWIG (for python wrapping at least). Real development of SWIG has somewhat stalled and it's not moving anywhere during the last years
Yep, you've got my thinking down exactly. For me the keys are 1) easy switching and 2) less maintenance. Especially on open source, I've found that the more you automate away what can be automated (e.g. automated builds, automated packaging, automated testing), the more you can focus on substantive improvements to your project rather than keeping it building and running smoothly. As an example, after switching to waf for the wxWebKit build system and having it automatically 'calculate' the list of files to build based on a set of rules about the directory tree rather than maintaining a list of files by hand, I was able to drop the number of 'build fixes' by about a factor of 8. In the same period, the Chromium port had about 140 commits related to build system updates, while wx had 26, and both were building largely the same tree. So I dropped the time needed to do routine maintenance on wxWebKit down possibly exponentially, which gave me more time to work on new features, bug fixes, etc.
Although things like this certainly require some upfront work, I also think the payoff of doing them is huge. Not just switching the binding tool, but adding new wrapper languages (see c_tools.py in that same dir) become possible as well with much less upfront effort. It's like a gift that just keeps giving.
Thanks,
Kevin
···
On Aug 22, 2010, at 6:09 AM, Matthias wrote:
Am 21.08.2010, 22:49 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:
-Matthias
--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
No, Kevin, just checking. I'm taking notes as I go so as I plan to
make suggestions for the build/install docs.
Thanks,
-Tom
···
On Sun, Aug 22, 2010 at 11:07, Kevin Ollivier <kevino@theolliviers.com> wrote:
Hi Tom,
On Aug 22, 2010, at 5:21 AM, Tom Browder wrote:
On Sat, Aug 21, 2010 at 15:02, Kevin Ollivier <kevino@theolliviers.com> wrote:
Yes, in wx trunk, build-wxpython.py configures and builds wxWidgets itself using some wxWidgets build scripts. This was done to remove a lot of the manual process found in BUILD.html for the 2.8 series of releases.
Hm, do I understand that I should have a clean wxWidgets source tree
before I start the build script? And it builds wxWidgets and wxPython?It doesn't need to be clean, but yes, it should build both wxWidgets and wxPython. Are you hitting an issue somewhere?