Replies: 5 comments 4 replies
-
I added a few things to force the behavior I was looking for. But what I'm not sure about is whether this was already supposed to happen? mottosso/maya_python_c_extension@e555b68 The key is in
Hence highlighting that we're able to access the already-loaded Maya plug-in from a newly loaded Python module, without the Maya plug-in explicitly being aware of the Python module. That's what I'm looking for. A completely separate Python module. It's relying on (possibly Window-specific) behavior of a dynamic library being loaded a second time returns a reference to the previously loaded library (much like how Python returns previously imported modules). It seems to work, and I think I can work around the differing methods for loading libraries between Windows and Linux. But the question is, have I implemented something different from the original intent of this repository? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mottosso: I'm not quite sure what you're trying to achieve specifically, but I'll try to go over your fork when I get a chance. Quick OTOH answers to your questions though:
The tutorial IIRC is demonstrating two approaches: one is having your exposing your Python extensions available upon loading the Maya plug-in immediately (though this has issues as discussed in the tutorial), and the second is building your Python extension as a conventional
Not sure I quite understand the question; the Python extension module is compiled with the logic "coming" from the plug-in; it isn't "re-defining" it: the hello world example shows the main logic in https://github.com/sonictk/maya_python_c_extension/blob/master/maya_python_c_ext_hello_world.cpp and the Python extension module binding is in: https://github.com/sonictk/maya_python_c_extension/blob/master/maya_python_c_ext_py_hello_world.cpp which references it. Dependencies or unity builds have nothing to do with it.
Looking at your two files very quickly, yea, I wouldn't expect you to define the same function that way; see above. That's not what is going on in the sample code provided.
This is not something the original tutorial implements for a variety of reasons, since what you're describing according to those steps is essentially modifying memory across DLL boundaries, which for me is generally a big no-no for several reasons (this being one of them: https://devblogs.microsoft.com/oldnewthing/20060915-04/?p=29723). Ideally both DLLs would be modifying memory already allocated by the host application instead of modifying memory that either of the DLLs have allocated themselves, unless you guarantee the allocation mechanisms are going to be the same for both. Or, if constraints allow, you could rely on the most classic way of inter-DLL/process communication: serializing to disk the data you're attempting to have both DLLs share and having both DLLs read from there instead, with additional synchronization mechanisms as needed. P.S. You could also consider the approach in the tutorial where you expose the Python bindings upon loading the Maya plug-in immediately, rather than having to load a separate Python (That doesn't mean you _shouldn't attempt the 4 steps you've outlined above, I've successfully done something like that in production before albeit for completely different reasons not involving Maya/Python, but I'd be interested in hearing the actual use case for this before recommending you go ahead with that sort of approach.) Hopefully that makes sense! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for getting back! I didn't phrase this question well. xD Cloning and building this repository, there are two translation units built: The "double definition" in the case of The "indirection" I am referring to is the includes-of-includes, namely that maya_python_c_extension/maya_python_c_ext_plugin_main.h Lines 7 to 15 in bdbc032 One of which is the definition for And that's where I get lost. It would mean both the In my example on the other hand, the import maya.cmds as cmds
cmds.loadPlugin("maya_python_c_ext")..which in turn performs startup code that modifies the string printed by const char* kHELLOWORLD = "Original Hello world from the Maya Python C extension!";
void helloWorldMaya() {
return MGlobal::displayInfo(kHELLOWORLD);
}
MStatus initializePlugin(MObject obj) {
MFnPlugin plugin(obj, kAUTHOR, kVERSION, kREQUIRED_API_VERSION);
kHELLOWORLD = "Modified Hello world!";
MStatus stat { MStatus::kSuccess };
return stat;
}So now, when the import maya_python_c_ext as ext
ext.hello_world_maya("")It would print.. Even though the calling Does that make sense? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, was sick for a while here. I'll double-check again; but OTOH the idea is that the tutorial demonstrates two completely different approaches, one being a .mll extension alone and one being a .pyd extension alone, so yes there should be two separate binaries being built but they should not be loaded simultaneously. I'll see if there is something in the unity build setup that makes this unclear. Again, I re-iterate: having the .pyd functions be able to affect memory allocated in the space of the .mll or vice versa is probably not a good idea under most circumstances. The reason why the export libs just overwrite each other in the build script is because frankly they're not necessary for runtime, so really they're not that important for the purposes of the tutorial. |
Beta Was this translation helpful? Give feedback.
-
|
Wuw, comments have comments here. :O
This doesn't make sense to me; the Maya Python API 2.0 modifies the memory allocated by the Maya C++ backend, the PySide2 bindings modify the memory of Maya's C++ Qt integration, the example in this repository e.g. I would go as far as to say that's the sole purpose of any Python bindings. What else should it do? Maybe you meant memory shouldn't be touched from two separate threads at the same time, to which I would agree but can't see any risk of here. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mottosso:
When you allocate/deallocate memory within the same DLL, that's fine. I'm referring to the earlier quote above: For example, if you had an integer defined in your Maya plug-in, made its symbol visible to your Python module, and allowed your Python module to modify it; that's an example of one DLL modifying memory allocated across DLL boundaries. That's not a good idea. You can, however, mostly rely on DLLs being able to modify memory allocated by the host process (which is what you described right above with the example this repo implements i.e. This is not the case here, but yes, in general, memory shouldn't be handled by two separate threads without synchronization mechanisms in place. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I've got a version that works for my usecase. Since I last posted, I was using
That was a relief, as it saved me from..
I've also summarised how I think my fork differs from yours, would be good to get your eyes on it to make sure nothing was overlooked. One of the more difficult-to-spot behaviors of the original set CommonLinkerFlags=... /implib:"%BuildDir%\%ProjectName%.lib"Which made it tricky to query the The last thing I still haven't wrapped my head around is how the I made a small modificiation to this repo to highlight that you are able to modify the behavior of the mottosso/maya_python_c_extension@a5bd137 But how? :O There is no call to In any case, thanks a lot for this example project, I've learnt a ton that was a complete mystery just a few days ago! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mottosso: I actually double-checked on this; again, I don't quite understand where you're seeing that in this repo the BTW, re. your notes about building on Maya 2020...you can do that in this repo easily simply by changing the directory Maya is found in and removing |
Beta Was this translation helpful? Give feedback.
-
|
I've broken my links since last time :( Ironically, the reason it broke was to avoid breaking in the future, by de-forking the repository. |
Beta Was this translation helpful? Give feedback.
-
Hi @sonictk,
Stumbled upon this tutorial via searching the interwebs for resources involving pybind11, and this hit the spot; I've got a C++ project with a custom node and want Python bindings for it, without including the C++ project into the Python project itself.
I've taken a crack at unrolling the unity-build and re-formatted the
.batto try and understand how things work, but there's one thing I cannot get my head around. In my fork I cannot get around including the definitions for functions exposed via Python into the Python module itself. I think the same applies to this original repository as well (though there are a-few-too-many layers of indirection for me to say definitively).Let's say the Maya plug-in was much larger and depended on a number of additional third-party dependencies (like Boost). In that case, I would expect a Python binding to merely reference the definitions coming from the plug-in, rather than re-define them. Is that the goal of this repository as well or did I misinterpret?
If so, I've managed to boil the project down into..
module_main.cppand..plugin_main.cppBut as you can see, they both provide definitions. I would expect only one of these to actually need definitions, preferably the
plugin_main.cppwhich I expect to run without the added Python bindings.Any suggestions?
Beta Was this translation helpful? Give feedback.
All reactions