Inlined functions in Python's header files result in unresolvable
symbols at link time when building in Debug config on Windows.
This downgrades the upper limit on Windows to 3.10 again until a proper
fix can be found.
macOS is unaffected because it can link binaries with dynamic runtime
lookup.
Prior code would not only iterate over possible versioned python DLL
names, but also replace possible named subdirectories contained in the
path string.
This commit changes the same code to only change the filename and leave
the path prefix intact.
Python automatically creates bytecode caches which end up inside the
application bundle of OBS Studio on macOS. These directories will lead
to a hash mismatch when Sparkle attempts to apply a delta update (to
ensure that the patch can be applied).
As the added directories will make the hash check fail, having a valid
Python framework configured in OBS Studio (even without any script
added) will thus prevent Sparkle from using delta updates.
Instead of using a non-debuggable macro function, keep function
references and desired function names in a static array that can then
be iterated over to add desired functions.
This allows for proper debugging as well as makes the combination of
function and function name more explicit.
When loading a new Python script, the GIL might be released while
importing the module, allowing the tick to run and change and reset the
cur_python_script state variable. Use the busy_script variable to save
and restore the value if not null.
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.