Set PYTHONPATH as needed in each of your build/run configs
I already set PYTHONPATH = $WXWIN\wxpython.
did you mean adding "$WXWIN\wxpython\wx\debug" and "$WXWIN\wxpython\wx
\release" to the PYTHONPATH also?
Yes. Separate the current and the build-mode paths with a semi-colon.
but there are exactly same files in these two folders, even though the
context of files are different.
I feel maybe something can be done in $WXWIN\wxpython\wx\__init__.py,
but I really don't know how.
before:
# Load the package namespace with the core classes and
such
from wx._core import *
del wx
after:
# Load the package namespace with the core classes and
such
if current_build == debug:
from wx.debug._core import *
del wx
else:
from wx.release._core import *
del wx
You could do something like that, but there really isn't a need for it. You probably are not going to want to distribute the files to your users with the release/debug dir structure, and in that case you certainly do not want to have to change the import code in what you are delivering to your users to be different than what you are developing and testing with. And you surely don't want to have to remember to reapply that change when you update your wxPython code to a new release.
The wxPython .pyd files are all imported directly without using the package name or a relative import[**] so if they are found on the sys.path then it will work. Changing the PYTHONPATH depending on which build you are running is a simple thing to do.
[**] In the code you have above wx._core is actually a .py module, that in turn does a "import _core_" to get the extension module.
Current situation:
1, "$WXWIN\wxpython\wx\debug" folder has 20 debug _pyd files.
2, "$WXWIN\wxpython\wx\release" folder has 20 release _pyd files.
3, I set PYTHONPATH = $WXWIN\wxpython\;$WXWIN\wxpython\wx\release,
now the demo.py can't get run.
4, I must copy all _pyd files to $WXWIN\wxpython\wx, (original tree
structure), to make demo.py run.
I think I know what is going on. I had forgotten that the usual import package name for the _core_ module is hard-coded in the other extension modules with this little gem:
So when the other extensions call this to get a pointer to wxPython's extra helper functions it is failing, and code later on that is trying to use that API is using a NULL pointer. And then BOOM.
There are probably some ways to work around this, but at this point it may be simpler to just copy files around when you want to switch between debug or release builds. Or you could restructure your build such that it makes 2 complete copies of the wxPython/wx tree (not just the extension modules) and then use PYTHONPATH to switch between which of those folders is seen first by the import.
···
On 1/4/11 7:16 AM, wofeib wrote:
I'm still in trouble.
Current situation:
1, "$WXWIN\wxpython\wx\debug" folder has 20 debug _pyd files.
2, "$WXWIN\wxpython\wx\release" folder has 20 release _pyd files.
3, I set PYTHONPATH = $WXWIN\wxpython\;$WXWIN\wxpython\wx\release,
now the demo.py can't get run.
4, I must copy all _pyd files to $WXWIN\wxpython\wx, (original tree
structure), to make demo.py run.
There are probably some ways to work around this, but at this point it
may be simpler to just copy files around when you want to switch between
debug or release builds. Or you could restructure your build such that
it makes 2 complete copies of the wxPython/wx tree (not just the
extension modules) and then use PYTHONPATH to switch between which of
those folders is seen first by the import.
Got it. thanks.
Another question: instead of hybrid build and debug build, does it
have a pure release build (without wxdebug defined)?
if yes, how to build that version? thanks.
On Jan 5, 11:09 am, wofeib <abb...@gmail.com> wrote:
> There are probably some ways to work around this, but at this point it
> may be simpler to just copy files around when you want to switch between
> debug or release builds. Or you could restructure your build such that
> it makes 2 complete copies of the wxPython/wx tree (not just the
> extension modules) and then use PYTHONPATH to switch between which of
> those folders is seen first by the import.
Got it. thanks.
Another question: instead of hybrid build and debug build, does it
have a pure release build (without wxdebug defined)?
if yes, how to build that version? thanks.
Yes. Well, the upper case version of those names anyway. Also for the wxPython build you need to add FINAL=1 so the wx release libs will be used.
OTOH, you'll want to be sure that you *really* want to get rid of the benefits that a hybrid build will give you. The runtime asserts are not much additional overhead and IMO it is worth the extra safety factor of being able to detect those errors at runtime. It is much nicer to get a report from your users of a PyAssertionError traceback rather than just a hard crash.
FYI, there is no need for hybrid build in 2.9 any longer, the default release build options now leave the assert statements active instead of disabling them.