libGLFW is not installed as part of the MaterialXGraphEditor target

[dgovil]

The MaterialXGraphEditor target has a dependency on libGLFW. However this does not get installed when building the graph editor, causing it to be non functional unless the libraries get copied over.

I see that it sets GLFW_INSTALL to OFF , which is oddly what the NanoGUI build does for the Viewer too.
I do however see that NanoGUI says this in its cmake

# Two targets have now been defined: `glfw_objects`, which will be merged into
  # NanoGUI at the end, and `glfw`.  The `glfw` target is the library itself
  # (e.g., libglfw.so), but can be skipped as we do not need to link against it
  # (because we merge `glfw_objects` into NanoGUI).  Skipping is required for
  # XCode, but preferable for all build systems (reduces build artifacts).

Perhaps something similar needs to be done for the GraphEditor so it doesn't have a hard link against libGLFW? or we need to enable the install.

Enabling the install however does cause this error to pop up during the build despite that file existing.

source/MaterialXGraphEditor/External/Glfw/CMake/cmake_uninstall.cmake.in does not exist.

However I do see the file exists on the nanogui side: MaterialXView/NanoGUI/ext/glfw/CMake/cmake_uninstall.cmake.in
So I just wanted to see if there was any insight on why the file was removed, and why the install is disabled? also if there were any ways we could move forward and either inline the symbols or install the lib?

[jstone-lucasfilm]

These are great notes, @dgovil, and we'd be happy to move forward with either NanoGUI-style GLFW merging or reenabling of GLFW installation. We disabled GLFW installation to keep its footprint as minimal as possible within MaterialX, but it would be fine to add this support back if that proves to be the most natural path forward.

[dgovil]

Ah yeah that makes sense why you did that.

I think either option you mentioned would be good. It would make the default build+install more intuitive for folks.

[nicolaspopravka]

Is this still an issue ?

My default macOS build of MaterialXGraphEditor for Dev Days seems functional without an install of GLFW, afaict. The resulting executable is simply statically linked against libglfw3.a at build time. Here are my steps to build and run it:

mkdir build
cd build
cmake  -DMATERIALX_BUILD_GRAPH_EDITOR=ON ..
cmake --build .
cmake --install .
installed/bin/MaterialXGraphEditor

Happy to look into this further if needed.

[jstone-lucasfilm]

Thanks for that note, @nicolaspopravka, and I'm CC'ing @dgovil to see if this is still an issue that needs to be resolved on macOS. I haven't encountered this issue in our Linux and Windows builds of MaterialXGraphEditor, but there may be dependencies on specific build choices or environments.

[dgovil]

Ah yeah I haven't hit this in a while either so I think it all works. I'll close this out.

[dgovil]

Actually, @jstone-lucasfilm we're seeing this again so maybe my testing wasn't thorough. I'll reopen and Lee has a proposed solution.

[ld-kerley]

I was digging through some stuff on outside and I think what Nicolas is saying above is 99% correct. If we link against glfw statically, then all will be good. But if MATERIALX_BUILD_SHARED_LIBS is set to ON (which is NOT the default). Then that propagates BUILD_SHARED_LIBS=ON down in to the glfw cmake build.

It looks trivial to amend that so we force glfw to always build static, which I think will take us that final 1% of the way to success - I'll put up a PR soon.