That is AWESOME! Thank you so much!!!
This actually allowed me to find a similar (but less pervasive) bug in the Python wrappers.
@dgobbi Thanks a lot! Iāve tested release
branch and it works now - at least my brief tests.
I also noticed that I cannot compile with OSMESA:
vtk/vtk-release/ThirdParty/glew/vtkglew/src/glew.c:41:12: fatal error: GL/osmesa.h: No such file or directory
41 | # include <GL/osmesa.h>
| ^~~~~~~~~~~~~
I do set OSMESA_INCLUDE_DIR and OSMESA_LIBRARY variables in cmake, and I set VTK_OPENGL_HAS_OSMESA to on. When I manually add -I<path to include>
to CXX flags, then things compile better, but linker fails. The same trick with adding -L<path to lib>
did not work - something always fails to link.
Any ideas? Do I do something wrong?
Can you show the values that you used for OSMESA_INCLUDE_DIR and OSMESA_LIBRARY?
I set the following values
OSMESA_INCLUDE_DIR /home/angainor/mesa/install/include
OSMESA_LIBRARY /home/angainor/mesa/install/lib/x86_64-linux-gnu/libOSMesa.so
When I run make VERBOSE=1
, the include path is not seen on the command line when compiling ThirdParty/glew/
. Thatās why I tried to add it explicitly to compile flags. I looks like CMake is not using those variables, or at least not everywhere where it should.
I suspect that you are right that those cmake variables are not being used, but unfortunately Iām not very familiar with OSMesa. Can you start a new discussion thread for your question?
Of course, thanks a lot for your help!
Could someone actually using Java bindings please confirm that https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6629 works for them?
Attempting to do this now, assuming I checked out the right branch, etc. Will let you know what I end up. Basically youāre looking for what ends up in the install dir for java related items, @ben.boeckel??
Iād like to know whether what is there is sufficient for you to get what you need from an install tree. If not, a list of what is missing would be very helpful (and its location in the build tree if you can find it).
Will do.
Just to keep you posted, I had some issues building last night (it seemed to have trouble finding the jogl/gluegen jars, even though they were specified via cmake), so I am trying again with my custom build script to see what happens.
Ah, I donāt think I tested with JOGL here. Trying it out.
I was able to get it to recognize the JOGL stuff with my custom build script (instead of going through ccmake) Iām just not sure why it was any different. Iām going to try to get a build done with my script, and then go back through doing it with ccmake to see if certain flags arenāt getting set (which I think is the case). A few to make sure:
VTK_JAVA_INSTALL = ON
VTK_WRAP_JAVA = ON
VTK_JAVA_JOGL_COMPONENT = ON
JOGL_GLUE = <Your glugen-rt.jar file here>
JOGL_LIB = <Your jogl-all.jar file here>
I havenāt totally confirmed yet, but Iām pretty sure some of those werenāt getting set via ccmake once VTK_JAVA_INSTALL got set to ON. At a minimum, VTK_WRAP_JAVA should get enabled at that point, and the JOGL ones should get exposed; when JOGL_COMPONENT is turned to ON, the last 2 should get enabled and prompted for. Does that make sense? Iām not a cmake expert by any means, but that sounds like the series of updates via ccmake that need to take place. Like I said, Iāll try to confirm that later.
This variable no longer exists; if Java is enabled, it gets installed (controllable via install components).
Theyāre advanced variables, but they are there.
OK. Let me know what you get with the JOGL stuff enabled - for some reason now Iām having problems again, like the jars arenāt getting recognized. shrug emoji
I think that target_link_libraries
with Java jar files doesnāt work as I thought it did. Seems I have to manually build up the -classpath
argument.
Iāve successfully built with JOGL using the current state of the MR. If we need other paths added to FindJOGL
to make finding it more automatic, please let me know.
Was the MR updated to recognize the class path? If not, were any special cmake fields besides what I mentioned above set?
Yeah, it just builds up a class path flag now.
OK copy that, let me pull and rebuild