Calling `PyEval_InitThreads` has been deprecated in Python 3.7 and the
function itself will be removed in Python 3.11. The current check
guards this function behind a version check that only happens at compile
time.
This in turn leads to crashes when run on Python 3.6, as the necessary
initialization for `PyEval_ReleaseThread` did not take place.
This commit ensures the manual initialization takes place based on the
runtime version of Python and avoids loading the associated symbols
on Python 3.9 or later.
This changes the way obs-scripting looks for and loads an available
Python 3 library. It tries to find a best possible version (starting
with Python 3.10) down to and including Python 3.6 by existing file
naming conventions and loads the most recent variant it can find.
User specified search path is either a Python installation directory
(Windows), or a Framework directory containing `Python.framework`
(macOS). The dll or dylib names are composed automatically.
The Python home path is also composed automatically on macOS (where
it has to point inside the Framework directory).
Fixes issues introduced by https://github.com/swig/swig/pull/2238. As
obs-scripting is not compatible with the SWIGPYTHON_BUILTIN, obspython
needs to disable this feature.
Due to swig using a hardcoded swig library path in self-compiled
variants, we need to pass our custom swig library path with every
invocation of swig on macOS.
CMake's `add_custom_command` function does _not_ inherit the environment
variables used during configuration, hence why it needs to be passed
explicitly on invocation.
Usage of CMake's "-E env" command module should allow for cross-platform
compatible invocation.
The obspython.i file requires `ENABLE_UI` to be defined for the swig
compiler to pull in the actual obs-frontend-api header. If this is not
the case, swig will not discover the required methods and ENUMs and
in turn will not make those available in the scripting environment.
The obslua.i file requires `ENABLE_UI` to be defined for the swig
compiler to pull in the actual obs-frontend-api header. If this is not
the case, swig will not discover the required methods and ENUMs and
in turn will not make those available in the scripting environment.
In Python 3.9+, `PyCFunction_New` and `PyCFunction_NewEx` are themselves
macros around `PyMethod_New`. To fix the warning, both macros need to
be untouched for those Python versions, instead the actual function
`PyMethod_New` needs to be imported and aliased.
This commit:
- Adds the import of the `PyCMethod_New` symbol
- Adds the function definition for `Import_PyCMethod_New`
- Adds the `PyCMethod_New` function alias
macOS uses runtime lookup for symbols in obs-scripting. While this guard
fixes a compiler warning, it also leads to the `_PyCMethod_New` symbol
being undefined.
In turn any library linking with obs-scripting will then fail to load
because of that undefined symbol. Removing this guard fixes that issue.
* obs-scripting: Fix unused 'varargs' warning
* obs-scripting: Fix PyEval deprecation warnings
Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() call for
Python 3.7 and later as Python calls it automatically now.
This removes deprecation warnings when using Python 3.9 or later.
https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads
Status output related to OBS configuration is prefixed with the string
"OBS" and added padding for enabled and disabled features. This padding
was not aligned between platforms.
By moving the padding and prefix decoration into its own function,
both elements are controlled in a single place. CMake scripts were
changed to use this new function `obs_status` instead of using CMake's
`message` function directly.
Makes the callback variable "removed" atomic, and on script unload,
first sets all callbacks to removed before actually unloading the script
out of a safety precaution. (See note at the bottom for further details)
This minimizes the possibility of a race condition where the script
callback could be called while those callbacks were being removed.
Big note for this change, this change should eventually be replaced with
a reference counting ownership method where script callbacks can hold a
reference and share ownership of the script if it's still alive while
the script callback is being called. That way the script callbacks can
safely execute. May require a fair amount of reworking of the script
object.
Deprecates:
obs_source_addref()
obs_output_addref()
obs_encoder_addref()
obs_service_addref()
obs_scene_addref()
These functions should be considered unsafe and not used. Instead, use:
obs_source_get_ref()
obs_output_get_ref()
obs_encoder_get_ref()
obs_service_get_ref()
obs_scene_get_ref()
These functions return a pointer to the incremented object only if the
object is still valid, otherwise they will return null, indicating that
the object is no longer valid or is unsafe to use.
The reason why this is being done is because certain third party plugins
seem to be using addref, and are somehow managing to call addref on
sources that have already been fully released. For the sake of safety,
almost all usage of these functions within OBS have also been replaced
as well.
Returning PyObject with borrowed reference will result in double free
and/or use after free issue. Issue seen as crash when running Python
script calling script_path().
Add PyDict_New and PyTuple_New to obs-scripting-python-import.[ch];
these functions are used by SWIG's generated code when I build OBS on
macOS with SWIG 4.0.1.
The current scripting directory path given to Python on OSX is
`../data/obs-scripting`. This works when bin/ and data/ are in the same
folder like rundir after a compile and in the old .app bundles but the
new normal .app bundle structure is different.
For bundles move obspython.py and _obspython.so to the binary folder,
just like the Lua one, and pass that bin path to the Python interpreter
so it can find it.
The current working dir isn't guaranteed to be set with .app bundles
so look up binary path at runtime.
_obspython.so currently links directly against python as @rpath/Python
and has 3 common python install paths set as rpaths so it would only
work if a user had python installed at one of those hardcoded paths.
Don't link _obspython against python at all but instead link it with
"-undefined dynamic_lookup" so when it is imported by python all it's
undefined python symbols get resolved at runtime against the user
supplied python instance loaded into the process earlier.
The rpaths aren't needed anymore this way.
The libpython .dylib files on MacOS are in the python_path/lib
subdir. The user supplied python_path still needs to be to the actual
python root and not lib/ as the root path get's used as python home dir
so just add lib/ when loading the dylib.
tytan652
PatTheMav
gxalpha
Kurt Kartaltepe
jpark37
jp9000
derrod
Scratch
Ryan Foster
Colin Edwards
Per Heed
Clayton Groeneveld
comex
Rat
Matt Gajownik
luz.paz