find_package glfw when NANOGUI_BUILD_GLFW=OFF #104
Conversation
Also include some missing CMake utilities for install logic.
|
Not exactly verify as before. I was attempting to develop things for the Variscite Dev kit. To get around this issue I started a WaylandGUI project forked from here. Targeting Wayland only. 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. |
Great news! Thanks so much for testing 🙂
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) Probably you already discovered this though
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.
That's my hope, at least get the cmake part fixed for now. Thanks again for your detailed response! |
… defs.
Not sure how I missed this. Prior to this commit the install logic
will succeed, but the previous target_include_directories calls
with $<INSTALL_INTERFACE> evaluate variables not yet defined.
Previously:
```cmake
set_target_properties(nanogui PROPERTIES
INTERFACE_COMPILE_DEFINITIONS
"NANOGUI_USE_OPENGL;NANOGUI_SHARED;NVG_SHARED"
INTERFACE_INCLUDE_DIRECTORIES "/nanovg"
INTERFACE_LINK_LIBRARIES "glfw"
)
```
where `/nanovg` does not exist, for example. Now (fixed):
```cmake
set_target_properties(nanogui PROPERTIES
INTERFACE_COMPILE_DEFINITIONS
"NANOGUI_USE_OPENGL;NANOGUI_SHARED;NVG_SHARED"
INTERFACE_INCLUDE_DIRECTORIES
"${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include/nanovg"
INTERFACE_LINK_LIBRARIES "glfw"
)
```
|
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)
<#103 (comment)>
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
<#104 (comment)>,
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
|
wjakob
force-pushed
the
master
branch
11 times, most recently
from
e9c6fc9 to
0f47fe0
Compare
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 🙂
Fixes #101.
Install tree for me with external glfw looked like this: