[build_usd.py] on macOS include ABI flags in python library name

[neilo-df]

Description of Change(s)

Prior to this change build_usd.py assumed the name of the python library on MacOS is always "libpython#.#.dylib". However, in practice the library name may also contain ABI flags ("d", "m" and "u") that indicate how the python installation was compiled.

Because of changes in the use of Python ABI flags, this patch is relevant for Python 2.7 and Python 3.x builds up to
3.7. Starting with Python 3.8 there is no longer an ABI distinction when the interpreter is compiled with pydebug ("d") or pymalloc ("m"). Starting with Python 3.3 and newer there is no longer an ABI distinction for wide Unicode ("u") support.

Fixes Issue(s)

• USD doesn't build properly on macos with a Python dylib that has pydebug, pymalloc or wide unicode enabled.

[neilo-df]

Ok, the build error see is because apparently, on macOS sysconfig.get_config_var('INSTSONAME') returns only a fragment of the path and not the dylib name itself when Python is compiled as a framework.

A more complicated way to go about this (which I was trying to avoid) would be to query the individual ABI flags.

[neilo-df]

With that last commit I'm just checking if sysconfig.get_config_var('INSTSONAME') is a string that ends in ".dylib", and if so we use that. Otherwise, we assume it's a framework, so we fall back to the old answer which is "libpython" + version + ".dylib".

[meshula]

Is this a custom build environment, or are you using some Python management environment where a non-framework build is the norm?

[neilo-df]

Hi Nick, it’s a custom build environment.

…

On Sep 15, 2020, at 5:40 PM, Nick Porcino ***@***.***> wrote:  Is this a custom build environment, or are you using some Python management environment where a non-framework build is the norm? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jtran56]

Filed as internal issue #USD-6346

[sunyab]

The issue addressed by here was recently reported in #1724 and fixed in 672ab92, which should be part of the next USD release. I totally missed that this PR was sitting here and apologize for that. Closing this out.