[Python.NET] success… pythonnet running in maya on osx64bit

[brad at fie.us]

sorry… clarification:

the .config needs to be set to "__Internal"

if you set it to "maya" it will only work from running mayapy

if you set it to "__Internal" it will work form both mayapy and maya.  That's a mono thing.  As an interesting fluke, you can use "maya" for mayapy and "mayapy" for maya.


On Jan 9, 2013, at 12:47 PM, "brad at fie.us" <brad at fie.us> wrote:

> success… pythonnet running in maya on osx64bit
> 
> It took a good amount of hacking.  But it does work.
> 
> I'm going to work on wrapping all my changes and fixes into a patch or two.
> 
> However, some general notes:
> 
> You need to build your own mono in 64 bit mode, because they don't ship a precompiled 64bit mono for OSX currently.  I found it easiest to make a custom Portfile for macports, to do this.  Basic instructions can be found on the mono project's website.
> 
> pythonnet desperately needs a configure script.  Most of what I've been doing is ripping out a lot of pkg-config stuff that is making assumptions about python and mono locations.  Apparently, someone put a whole bunch of hard-coded ubuntu paths in there.  Once I've finished doing that, I can actually do what I need to do.  Which is tell the build system where my 64bit mono is, and which python to use.
> 
> in my case that's:
> 
> export PKG_CONFIG_PATH=/path/to/my/mono/pkgconfig
> make PYTHON=/Applications/Autodesk/maya2013/Maya.app/Contents/bin/mayapy
> 
> The makefiles themselves should not be finding mono-2 and glib-2.0.  They should assume them to be available to pkg-config already.  Finding them is something for a configure script.  And I'd argue it probably should set the python as well.
> 
> I had to hack up Python.Runtime.dll.config and tell it to "link" to "maya" rather than some form of "python26."  Python is statically linked into maya, as it is with a lot of 3rd party embedded python implementations.  The symbols it wants to link to, are in the maya binary, not a shared library.
> 
> So from a build system point of view, I'm thinking the two big takeaways are:
> 
> it REALLY needs a configure script.
> 
> Python.Runtime.dll.config probably needs to be generated as part of the build process and listen to the configure script as to where to point itself.  If I know where to point it to, during the build, I should be able to configure that as part of the build process.
> 
> Anyhow.  Those are my thoughts.  I'll try and send off some patches once I do some cleaning up.
> 
> -brad
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet