SWIG Binary

Hello!

I'm trying to compile wxPython 2.9.3.1 since I made small changes to the
interface files and need wxpython as a monolithic build, but I can't
seem to find the SWIG binary which should be located in
NameBright - Coming Soon according to the readme file (The
link is dead).

Try http://wxpython.kosoftworks.com/tools/ instead.

The documentations are very clear about using wxPython but not so much
about embedding it (I have checked out the sample),

When I compile wxPython (monolithic), will I then get a .dll/.lib file
which can be linked to? Because it seems that several .pyd files are
generated and I would rather have a single dll.

You should be linking to the wxWidgets .dll/.lib files, not to wxPython's .pyd files. Those are just the extension module code (what you get when there is an import statement in Python) and they also link with the wxWidgets .dll files so you need to make sure that both wxPython and your application are loading the same wx dll. A monolithic build will combine the wxWidgets build into a single dll/lib, but there will still be multiple wxPython .pyd files. There is not an easy way around that.

Will python 2.7 be abandoned when phoenix gets mature enough?

No, I expect that we'll continue supporting Python 2.7 as long as there is a significant percentage of people still using Python 2.7.

I would
rather use phoenix but it seems somewhat incomplete.

Yep, but it's getting there.

···

On 7/7/12 5:00 PM, Allonii wrote:

--
Robin Dunn
Software Craftsman

You should be linking to the wxWidgets .dll/.lib files, not to
wxPython’s .pyd files. Those are just the extension module code (what
you get when there is an import statement in Python) and they also link
with the wxWidgets .dll files so you need to make sure that both
wxPython and your application are loading the same wx dll. A monolithic
build will combine the wxWidgets build into a single dll/lib, but there
will still be multiple wxPython .pyd files. There is not an easy way
around that.

Yes, I already have a monolithic build of wxwidgets 2.9.3, in which I get a single dll. I also compiled Python core and have the same result.
Now I would like the same for wxpython, that is get a single dll instead of several pyd files. Instead of load the modules from pyd files which are essentially .dll files there must be a way to just include the headers and sources and by that just create a single dll.

It's possible, but not out of the box. You would have to totally change how the build is done, linking all the extension modules together, and add some bootstrap code that will "import" all of the other extensions when _core_ is imported so they are already there when their .py modules are imported. Doesn't seem to be worth the effort to me, there is no real advantage to doing this instead of how things are now, other than slightly reducing the file count.

···

On 7/8/12 6:30 AM, Allonii wrote:

    You should be linking to the wxWidgets .dll/.lib files, not to
    wxPython's .pyd files. Those are just the extension module code (what
    you get when there is an import statement in Python) and they also link
    with the wxWidgets .dll files so you need to make sure that both
    wxPython and your application are loading the same wx dll. A
    monolithic
    build will combine the wxWidgets build into a single dll/lib, but there
    will still be multiple wxPython .pyd files. There is not an easy way
    around that.

Yes, I already have a monolithic build of wxwidgets 2.9.3, in which I
get a single dll. I also compiled Python core and have the same result.
Now I would like the same for wxpython, that is get a single dll instead
of several pyd files. Instead of load the modules from pyd files which
are essentially .dll files there must be a way to just include the
headers and sources and by that just create a single dll.

--
Robin Dunn
Software Craftsman