Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

find_package glfw when NANOGUI_BUILD_GLFW=OFF #104

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

find_package glfw when NANOGUI_BUILD_GLFW=OFF #104

wants to merge 2 commits into from

Conversation

svenevs
Copy link
Collaborator

@svenevs svenevs commented Jan 19, 2022

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:

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

7 directories

@svenevs
find_package glfw when NANOGUI_BUILD_GLFW=OFF
19cac59 
Also include some missing CMake utilities for install logic.
This was referenced Jan 19, 2022
Open
Open
@RolandHughes
Copy link

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.
ldd-of-example

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

image

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 svenevs mentioned this pull request Jan 21, 2022
Open
@svenevs
Copy link
Collaborator Author

svenevs commented Jan 21, 2022

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) 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!

@svenevs
[squash this] include(GNUInstallDirs) sooner for $<INSTALL_INTERFACE>…
31fd095 
… 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"
)
```
@RolandHughes
Copy link

RolandHughes commented Jan 21, 2022 via email

@oikumene oikumene mentioned this pull request Apr 10, 2022
Open
@wjakob wjakob force-pushed the master branch 11 times, most recently from e9c6fc9 to 0f47fe0 Compare October 27, 2022 21:06
@RolandHughes RolandHughes mentioned this pull request Nov 2, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

GLFW cmake issue when trying to use -DNANOGUI_BUILD_GLFW=OFF
2 participants
@svenevs @RolandHughes