Recursively search for library paths for Viewer and Editor

[kwokcb]

Fix #1292

• Add utility to iteratively search upwards for a libraries folder from a start path.
• Use the module path as the start path for both the Viewer and Node Editor.

This fixes when the binary is in the same folder as the libraries folder.

Note that this does not affect MaterialX test since it already searches in the same folder as the test binary.

[jstone-lucasfilm]

@kwokcb This might deserve some deeper investigation, as it's not an issue that's been reported on MacOS before. Does this only apply to developer builds, or does it apply to the shipping builds of the viewer in releases? If we can narrow this down further, then we should be able to implement a more targeted solution.

[kwokcb]

Hi @jstone-lucasfilm,
This does not occur with the installed folder as MaterialXView is in a subfolder below libraries. For builds,
with my current configuration MaterialXView is at the same level as libraries so always fails.

If anyone sets up MaterialXView at the same level as libraries then it will fail, so I think this is a suitable patch.
It also feels strange to always only look for libraries in the parent folder of the binary.

[ashwinbhat]

Hi @kwokcb
What does the output layout look like on Ventura? Are you creating application bundle?

[kwokcb]

For builds which only create one build area, there is no subfolder for the build type (e.g. Release/RelWithDebugInfo/Debug).
Thus the executable is in the same folder as libraries. I was using -GXcode which created the separate build areas and am no longer doing so (I'm basically trying to build exactly as CI does as the multiple build case does not create Python executables with the correct architecture for M1/M2 etc.).

@ashwinbhat, neither the build area or installs create bundles so it's always possible to move files around and have libraries not found. I guess this would be the best way to handle this, but it's not currently being done.

[jstone-lucasfilm]

@kwokcb I like the idea of generalizing this function further, and one option would be to traverse from the module path to each parent path (e.g. self, parent, grandparent, etc.), returning the first folder that contains the expected data libraries subfolder. This would remove the distinction between "install" and "development" paths in getDefaultSearchPath, and would theoretically maintain the current behavior for existing users of MaterialX example applications.

[kwokcb]

@jstone-lucasfilm , this sounds like simple logic to add. As the Graph Editor also follows the same logic it will also need to be updated as it is also failing when in the same folder as libraries. I have created a utility which starts from any root to do the searching.

[jstone-lucasfilm]

This looks good to me, thanks @kwokcb!