Tweak CMakeLists.txt with necessary OpenGL and GLFW changes to get Linux/Wayland working #135
Conversation
ashpil
force-pushed
the
cmake-glfw-changes
branch
from
43f3e85
to
a98adf1
Compare
|
Though its worth noting that in Wayland application window sizes are just requests, and the compositor gets priority, leading to this weirdness: For some projects I also get a different issue (the window not showing up at all despite program running), but I figure I'll investigate that once I get this actually merged in. |
| set(GLFW_BUILD_INSTALL OFF CACHE BOOL " " FORCE) | ||
| set(GLFW_INSTALL OFF CACHE BOOL " " FORCE) | ||
| set(GLFW_USE_CHDIR OFF CACHE BOOL " " FORCE) | ||
| set(GLFW_INSTALL NANOGUI_INSTALL CACHE BOOL " " FORCE) # install GLFW if nanogui install requested |
There was a problem hiding this comment.
This is odd but I believe has the desired effect.
| GLFW_DOCUMENT_INTERNALS GLFW_INSTALL GLFW_USE_CHDIR GLFW_USE_MENUBAR | ||
| GLFW_USE_OSMESA GLFW_VULKAN_STATIC GLFW_USE_RETINA GLFW_USE_MIR | ||
| GLFW_BUILD_DOCS GLFW_BUILD_EXAMPLES GLFW_BUILD_TESTS | ||
| GLFW_INSTALL GLFW_USE_OSMESA GLFW_VULKAN_STATIC |
There was a problem hiding this comment.
Removed options that GLFW no longer uses.
There was a problem hiding this comment.
Been looong time since I looked under hood at NanoGUI. Why did you drop GLFW_USE_MENUBAR? I'm asking because I wonder if this precludes having a nice menu bar with NanoGUI on Wayland. If I'm off in the weeds with this question feel free to say so. I've been deep in CopperSpice and CsScintilla lately.
| if (NANOGUI_BACKEND STREQUAL "OpenGL") | ||
| list(APPEND NANOGUI_LIBS GL) | ||
| find_package(OpenGL REQUIRED COMPONENTS OpenGL) | ||
| list(APPEND NANOGUI_LIBS OpenGL::OpenGL) |
There was a problem hiding this comment.
There's a possibility that this will not work with non-GLVND linux systems, though I can't tell how common these systems actually are. CMake's FindOpenGL module doesn't provide clear guidance on the correct cross-platform solution here.
| @@ -564,10 +547,10 @@ if (NANOGUI_BUILD_EXAMPLES) | |||
| add_executable(example4 src/example4.cpp) | |||
| add_executable(example_icons src/example_icons.cpp) | |||
|
|
|||
| target_link_libraries(example1 nanogui) | |||
| target_link_libraries(example1 nanogui glfw) | |||
There was a problem hiding this comment.
This is odd as well, though without it I get error adding symbols: DSO missing from command line. It's something to do with nanogui shared vs static, this error doesn't occur if NANOGUI_BUILD_SHARED=0 is specified.
There was a problem hiding this comment.
I have two further questions
- Did you test this with the switch mentioned in this thread? find_package glfw when NANOGUI_BUILD_GLFW=OFF #104
- Why don't we completely rip out GLFW and make the system GLFW a dependency? The custom features were a problem and if they are no longer used I would think it simpler for long term maintenance to remove GLFW from the repo and all of the build logic for it.
Thinking out loud before I've finished the first Diet Dew of the morning . . .
Your target link libraries issue above is because "static" has the GLFW currently built into it while shared builds a GLFW library, parks it somewhere, then, most likely, the CMakeLists.txt doesn't add the library to the project.
If you are using Ubuntu, you can test the above by simply removing that glfw addition and installing the Wayland glfw package:
https://packages.ubuntu.com/search?keywords=glfw
Everything should build and run. If you ldd the executable you will see it uses the system glfw
While I hate stack overflow, this message thread has a good explanation of adding libraries
https://stackoverflow.com/questions/39598323/how-to-properly-link-libraries-with-cmake
This is the path I was on with the WaylandGUI fork. Life gets a lot easier if you just use the system GLFW. There is even a .cmake to make it easy to add.
roland@roland-HP-EliteDesk-800-G2-SFF:/$ sudo find -iname *glfw*
[sudo] password for roland:
find: ‘./run/user/1000/doc’: Permission denied
find: ‘./run/user/1000/gvfs’: Permission denied
./usr/share/doc-base/glfw3
./usr/share/doc/libglfw3-doc
./usr/share/doc/libglfw3-dev
./usr/share/doc/libglfw3-dev/examples/glfw.rc
./usr/share/doc/libglfw3-dev/examples/glfw.ico.gz
./usr/share/doc/libglfw3-dev/examples/tests/glfwinfo.c.gz
./usr/share/doc/libglfw3-dev/examples/glfw.icns.gz
./usr/share/doc/libglfw3-dev/html/glfw3_8h_source.html
./usr/share/doc/libglfw3-dev/html/structGLFWvidmode.html
./usr/share/doc/libglfw3-dev/html/glfw3native_8h_source.html
./usr/share/doc/libglfw3-dev/html/structGLFWgamepadstate.html
./usr/share/doc/libglfw3-dev/html/glfw3_8h.html
./usr/share/doc/libglfw3-dev/html/structGLFWgammaramp.html
./usr/share/doc/libglfw3-dev/html/structGLFWimage.html
./usr/share/doc/libglfw3-dev/html/glfw3native_8h.html
./usr/share/doc/libglfw3-wayland
./usr/share/lintian/overrides/libglfw3-wayland
./usr/lib/x86_64-linux-gnu/libglfw.so.3
./usr/lib/x86_64-linux-gnu/libglfw.so.3.3
./usr/lib/x86_64-linux-gnu/libglfw.so
./usr/lib/x86_64-linux-gnu/pkgconfig/glfw3.pc
./usr/lib/x86_64-linux-gnu/cmake/glfw3
./usr/lib/x86_64-linux-gnu/cmake/glfw3/glfw3Config.cmake
./usr/lib/x86_64-linux-gnu/cmake/glfw3/glfw3Targets.cmake
./usr/lib/x86_64-linux-gnu/cmake/glfw3/glfw3Targets-none.cmake
./usr/lib/x86_64-linux-gnu/cmake/glfw3/glfw3ConfigVersion.cmake
./usr/include/GLFW
./usr/include/GLFW/glfw3native.h
./usr/include/GLFW/glfw3.h
Just my 0.0002 cents
On my Wayland machine, if I supply the
GLFW_USE_WAYLAND=ONoption to cmake via the command line, this allows me to compile the code and run the resultant binary successfully.I'm no cmake wizard, so I had some trouble getting this to work with the prior
glfw_objectsworkflow -- instead, I switched nanogui to just use GLFW the way it recommends. As part of this, I switched the submodule to the main GLFW repository, as as far as I could tell, the custom features provided by the fork were no longer used. This means GLFW will be easier to update in the future.I've tested this on Linux/X11 and Linux/Wayland, and I can confirm this works on both, but I don't have a Windows or Mac machine to test whether I broke something there.
I expect this to fix #103.