PyOpenAL icon indicating copy to clipboard operation
PyOpenAL copied to clipboard

Library loading overcomplicated

Open Artoria2e5 opened this issue 1 year ago • 0 comments

Library loading isn't great right now. It works, but it does unnecessary things and changes things that should not be changed.

In library_loader.py:

load_other

PATH change will not affect library resolution at all on Linux, macOS, or FreeBSD. The semicolon also is not how they do PATHs. The current code only serves to destroy the last entry of $PATH.

arch_style: Is this permutation really necessary?

On Windows, the standard name is always just "OpenAL32", regardless of architecture, because history. With how al_lib loads things, the correct value is empty in the common case. In the uncommon case a user is really shipping and naming the dll, the arch bits might make sense, but all these aliases? How hard is it to have the user fix a name?

On "Other", the basic name is just "openal". When 32 and 64 coexist, they usually reside in different folders, but can also huddle together in the same fat binary, or have a name difference. In any case, the loader should not touch it, because Python's magic knows better. It will consult ldconfig on os.name == "posix", which is the real authority and has arcane magic better than everyone here.

_windows_styles

The lib{} bit is surprisingly justified, because MinGW calls it libopenal-1.dll. It still would not work though.

But _dynamic? Why would anyone name a dll that? If it's static, it would not be a dll...

_other_styles

The lib{} bit is not justified because Python knows to add it on mac and to, again, consult the Old Ones on other systems.

In al_lib.py

soft_oal being in front is a bit opinionated for an "OpenAL" library. alsoft is very cool, but doing this just doesn't do what it says on the bottle. The constants for alsoft's fun extensions also aren't there.


Recommendation:

  • remove all the styles except lib{} for win.
  • remove the path handling completely. it's not even used by al_lib!
  • define a way to bypass the search logic and call ctypes.CDLL directly at import for actually usable customization (you don't even need find_library: it's either there or not there, and LoadLibrary / dlopen knows more about the paths). Maybe an environmental variable, since passing stuff at import is pretty difficult.

Artoria2e5 avatar Apr 28 '23 11:04 Artoria2e5