GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
At the core this change adds two things:
This is in preparation for a removal of xbmc/interfaces/python
This commit adds an alternate addon library where a codegenerator creates all of the CPython code that bridges a native implementation to Python. This is nowhere near ready but I wanted to get it in front of people.
What you need to do to try it out:
Upon a successful make there will be a directory created with a bunch of generated source code here:
this means there will be these new directories:
Ideally the engines should be binary addons downloaded when a scripting addon requires it (like the python) - but I'll leave that for later.
I could merge the engines and bindings directories if anyone thinks that's more straightforward.
Then I need to make sure all of the platforms build with the new directory structure.
As usual, feedback is appreciated.
then can it at least be split to reflect these two logical bits?
Ok, cleaned up the native addon redundancy. @cptspiff - this should be less redundant redundant
Thanks @garbear !
C1fac67. I don't see a modulexbmcaddon.cpp/h in the list of files. maybe not necessary?
The ModuleAddonXXXX.h/cpp files only hold the non-class module methods. The addon module doesn't have any. The module definitions are in the xbmc/interfaces/swig directory and end in a '.i' which is a SWIG interface file. There's one per module.
Just as an FYI there is a problem in the way I integrated the generation of the SWIG bindings into the VS project. Currently the bindings are generated on every compile but I'm not yet sure why. It should only happen when the .i files have changed or when the generated files don't exist. But there's something screwed up with the VS project file.
What do you think of this: http://msdn.microsoft.com/en-us/library/e85wte0k.aspx
and the reference to "Custom Build _Step_s" here: http://msdn.microsoft.com/en-us/library/dd293663.aspx
It looks like you can add a "step" to a build and not necessarily override the entire build rule. I can play with this over next weekend.
Maybe that's a step in the overall build process. I'm not sure. It does say "The step can specify a command line to execute, any additional input or output files, and a message to display. If MSBuild determines that your output files are out-of-date with regard to your input files, it displays the message and executes the command."
I gave it a shot and there are at least two problems:
The custom build step command could look like this
FOR %%f IN ($(SolutionDir)..\..\xbmc\interfaces\swig\*.i) DO CALL $(SolutionDir)..\BuildDependencies\GenerateSWIGBindings.bat %%~dpf %%~nf
or could be put into another BAT file (slightly modified) and then called from the custom build step.
Nice. Trivial thing for such a huge a huge pull request but the XBMC licenses need to be updated :)
Ok. That should fix it.
Thanks everyone for all of your help.
EDIT: Moved the TODO List into the main message at the top. I'll keep it up to date.
8) Update the License text.
As already mentioned you'll want 10f8ee48af87a72166d042c6fc4acd058e5a66b9 for win32. Furthermore I still don't have a solution for re-generating the python files if a header file in xbmc/interfaces/native changes. And right now I get an exception as soon as I try to start XBMC. The exception is somewhere in WinMainCRTStartup() (some win32 specific C++ initialization code) specifically in _cinit().
Generally I agree with your re-structuring. Only "apidef" sounds a bit odd to me.
The crash is unrelated to the nature of my changes. It's because XBPython compilation unit must now be initialized later than the Announcement code and therefore the static call to CAnnounementManager::AddAnnouncer called from the constructor of XBPython (which is called when the XBPython.o compilation unit initializes due to the global g_pythonParser) is executed prior to the static elements (one of which is a std::vector) have been constructed.
The fix is ugly.
Yup that fixes the exception. Nice find.
I have one more commit with a few cosmetics in the VS project file: 7f9c655f3e414b30e566fc44ca3e49f1b08d5b4f
These unneeded tags were added while I played around with the different build events etc.
Is this broadcasted to the bindings elsewhere?
Good catch. This is part of TODO 7 in the list on the main PR message. After thinking about a better way to do this and talking to @amet over the weekend, I'll be putting this back in.
I haven't had time to go through all the code yet but I'm guessing this is to handle methods bound to an object? Would it perhaps make sense to use that naming instead? If handler is more accurate thats fine, just something which popped in when I was reading
Yes. This is now called just 'Callback' (one of the above commits removes all of the extraneous 'Addon' labels to all of the classes). All of this infrastructure is mainly to support python's inability to deal with calls from arbitrary threads - so we need to shuffle calls over to a thread currently running a script, and wait for that thread to call back into a method we have control over, before we can actually execute the callback.
To do this there's two main abstractions. The first is a 'Callback' which is a root class for a set of templates (CallbackFunction) for binding a call and it's parameters to an object (like you said). Here's an example of how it can be used:
Callback<MyClass, int>* callback = new Callback( myObj, &MyClass::doSomething, 5 );
This assumes that there's a class called MyClass with a method called 'MyClass::doSomething(int).' When you call 'execute' on the callback at some later point then 'myObj->doSomething(5)' will be called.
Looks awesome :)
Add a new native library that follows the Python API.
Add the groovy jars to be used in the codegenerator.
Add Groovy based codegenerator to tools.
[win32] @Montellese's addition of swig and doxygen win32 build depend…
Add swig interface files to be used by the codegenerator.
[fix] AnnouncementManager global order dependency.
Small addition to XbmcCommons::Exception.
@Montellese, @Memphiz, @jimfcarroll Replace the scripting engine wit…
…h a codegenerated one.
Merge pull request #901 from jimfcarroll/codegenerated-addons
Replace the entire scripting engine with one that's code-generated
Well fought :D
Sorry for resurrecting this PR, but I suspect that it broke music playback on an addon I'm working on: Spotimc.
The addon relies on an embedded python server (spawned from the addon itself) to serve music streams to XBMC via http. It worked before this PR was merged, but since then all requests to this embedded server end up on timeout errors.
If I'm not wrong, the python bindings for the xbmc module that were superseded by this PR released the python GIL with CPyThreadState, as you can see on the body of Player_Play:
I believe that the new implementation does not release the GIL, and these steps could end up causing the issue:
Hope these statements are true, and are able to explain the issue I'm experiencing.
Thanks in advance.
Ah. No problem resurrecting the PR. If you're right then the fix is trivial. I didn't really want to release the GIL for short lived method calls that quickly return to python and the Player.play method should kick off the player and return. We can try a fix if you can rebuild the code. Can you add a "DelayedCallGuard" to the top of the playStream method in Player.cpp (you can find an example of a DelayedCallGuard in the Player destructor). Let me know if that resolves your issue and I'll put a fix in.
Tried rebuilding XBMC, adding the suggested line on top of Player::playStream()'s body, with no results. The function's initial code now looks like this:
void Player::playStream(const String& item, const xbmcgui::ListItem* plistitem, bool windowed)
CLog::Log(LOGDEBUG, "in Player::playStream()");
As you can see, I also tried adding some debug statements here and there, but they won't get printed on the log file. The file I'm supossed to change is /xbmc/interfaces/legacy/Player.cpp, right?
Sorry if I did something wrong, I'm new to this :)
If you need help please use the XBMC forum.
Posting you questions here will send a notification to a lot of people which we rather avoid
@mazkolain, That's exactly right. You'll need to help me reproduce it. I guess we should move to the Developer forum. I'll look for your post. You'll need to explain how to reproduce it. Thanks. Sorry for the trouble.
I've moved the discussion of the issue to the XBMC forum as suggested:
Sorry for the noise...
@jimfcarroll we lost the original functionality here, it was supposed to reset subtitle delay to 0 when activating new subtitle.
see here https://github.com/xbmc/xbmc/blob/Eden/xbmc/interfaces/python/xbmcmodule/player.cpp#L509
any reason you removed that?
Should this be playCurrent()?
(sorry for commenting on such a large diff)