find_package glfw when NANOGUI_BUILD_GLFW=OFF

[svenevs]

Also include some missing CMake utilities for install logic.

I think those files get included into the scope via the GLFW cmake build somehow which would explain why this went unnoticed :slightly_smiling_face:

Fixes #101.

Install tree for me with external glfw looked like this:

$ /tmp/nanogui/
├── include
│   ├── nanogui
│   └── nanovg
├── lib64
└── share
    └── cmake
        └── nanogui

7 directories

[RolandHughes]

Not exactly verify as before. I was attempting to develop things for the Variscite Dev kit. https://www.variscite.com/product/evaluation-kits/var-som-mx8m-plus-evaluation-kits/ That's when I first hit the issue. Their XWayland support was jacked so I tried to build using their GLFW. I retested in the Debian 11 area where I was also testing. The Variscite board has been shipped back to client as we won't be using it going forward. They just don't have any software support people.

To get around this issue I started a WaylandGUI project forked from here. Targeting Wayland only. https://github.com/RolandHughes/waylandgui

I can tell you that what you have builds under a Debian 11 Wayland environment using this cmake

cmake -Wno-depreicated -Wno-Error=depricated -DNANOGUI_BUILD_PYTHON=OFF -DNANOGUI_BUILD_GLFW=OFF ..

I can also tell you there will be other issues with this. Using GLES 3 you will find it references something that only exists in the GLFW source included with this project. If you pull the sources from my project/fork into a directory and perform a diff with Meld, ignoring CMakeLists.txt you should find rather quickly what it was/is. I don't know if it is a deprecated feature that is now officially gone of if someone added something just to make something work for themselves. I just know that something which is in the glfw source for this project isn't in the official project source and you can't build without making changes.

I'm not working on that project right now and kind of pressed for time. I do still have my Toradex board so when I get back to working on WaylandGUI I can tell you more and test your branch again. I got really far.

Here's a snippet of an email I sent my client before we pulled the plug on the Variscite. There is another issue with GLES 3 and external GLFW

The string handling creating the shaders in those two examples cause a stack dump. My client and I agreed to pull the plug on the Variscite stuff so I didn't dig any further into it. I will dig further into it once I get everything else I'm working on out o the way. I'm about to start a rather intense billable project so "free" time will be limited and I have two higher priority "free" projects in front of the WaylandGUI project kicking what I find back to NanoGUI.

The Linux build dependencies for NanoGUI install libglvnd and that library jacks a lot of Wayland/Weston/Vivante (maybe it's all Vivante's fault?) environments. Given the Linux community's push to abandon X11, I don't see anyone fixing the issue any time soon. It's a tool to make people convert to Wayland.

If all you were trying to do was fix the cmake error I reported, I guess you can call it George and merge it.

If you were trying to fix external GLFW support, you will have to look at the src in my fork. I don't have 100% of it fixed which is why I've said nothing. Those two example programs might have to be tweaked.

[svenevs]

I can tell you that what you have builds under a Debian 11 Wayland environment using this cmake

Great news! Thanks so much for testing :slightly_smiling_face:

I just know that something which is in the glfw source for this project isn't in the official project source and you can't build without making changes.

There's a slightly related conversation (at least regarding wayland) going on, I added some notes about how the nanogui glfw fork works here https://github.com/mitsuba-renderer/nanogui/issues/103#issuecomment-1018146086 Probably you already discovered this though

I'm about to start a rather intense billable project so "free" time will be limited and I have two higher priority "free" projects in front of the WaylandGUI project kicking what I find back to NanoGUI.

No problem at all, I know that story. Right now I'm trying to fix small issues here but I'm getting the impression that wayland support may or may not be something that can get fixed easily (based off a quick look at your fork). The larger picture with wayland vs x11 vs ... etc is a complicated beast, and it's not clear. I think the first step would be wayland support on x86 will probably be the first step.

If all you were trying to do was fix the cmake error I reported, I guess you can call it George and merge it.

That's my hope, at least get the cmake part fixed for now. Thanks again for your detailed response!

[RolandHughes]

I think my "Wayland only" fork will be the way the project has to go in the future. I ripped out Apple, Windows, everything else to focus on Wayland only.

I did that because I'm lazy when it comes to fixing other people's code. I initially was going to go pure Vulkan but there was already a GLFES shader kind of thing in existence and I didn't want to dump the time into learning about it.

For a simple UI tool like this I only care about embedded Linux on ARM because that is 98% of where it will get used. CopperSpice is a really free really OpenSouce fork of Qt 4.8 (Unlike Qt which is basically no longer OpenSource given all of the licensing shenanigans). CopperSpice crew hasn't completed their port to ARM. Eventually they will so the really involved embedded UIs will go that way "just because it is there."

For embedded systems with simpler UI needs, a version of NanoGUI running on pure Wayland with most of the enhancements I've listed on the page will kind of rule the land. This X11 based NanoGUI is going to be a legacy project given the ever shrinking world of X11.

I have one other that says he will be joining me as soon as life settles down. I expect in another month or two we will make headway on it because he has a Variscite board. With just those two boards we can test against > 80% of the SOM based systems. Advantech can't ship a kit for at least 30 weeks.

Roland

On 1/20/22 10:09 PM, Stephen McDowell wrote:

I can tell you that what you have builds under a Debian 11 Wayland
environment using this cmake

Great news! Thanks so much for testing 🙂

I just know that something which is in the glfw source for this
project isn't in the official project source and you can't build
without making changes.

There's a slightly related conversation (at least regarding wayland) going on, I added some notes about how the nanogui glfw fork works here #103 (comment) https://github.com/mitsuba-renderer/nanogui/issues/103#issuecomment-1018146086 Probably you already discovered this though

I'm about to start a rather intense billable project so "free"
time will be limited and I have two higher priority "free"
projects in front of the WaylandGUI project kicking what I find
back to NanoGUI.

No problem at all, I know that story. Right now I'm trying to fix small issues here but I'm getting the impression that wayland support may or may not be something that can get fixed easily (based off a quick look at your fork). The larger picture with wayland vs x11 vs ... etc is a complicated beast, and it's not clear. I think the first step would be wayland support on x86 will probably be the first step.

If all you were trying to do was fix the cmake error I reported, I
guess you can call it George and merge it.

That's my hope, at least get the cmake part fixed for now. Thanks again for your detailed response!

— Reply to this email directly, view it on GitHub https://github.com/mitsuba-renderer/nanogui/pull/104#issuecomment-1018156610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLYVCKWR2U5L2GXWSBUC3UXDMAJANCNFSM5MI6I6GA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

-- Roland Hughes, President Logikal Solutions (630)-205-1593

http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog