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, "b...@fie.us" <b...@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@python.org > http://mail.python.org/mailman/listinfo/pythondotnet _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
