The VTK maintenance team is happy to announce that VTK 9.0 has entered the release candidate stage!
You can find the source, data and documentation tarballs here.
Take a look at the VTK wiki for a complete list of API changes in v9.0.0 over the previous version.
Please try this version of VTK, and report any issues to the bug tracker so that we can try to address them before VTK 9.0.0 final. Kindly set the 9.0 milestone on your issue and merge requests for 9.0 to ensure that they are tracked during the remainder of the release process. Further, please base / rebase all 9.0 target branches off of the v9.0.0.rc1 tag to ensure minimal merge conflicts with the release and master branches.
The official release notes will be available when VTK 9.0.0 final is finished in the next few weeks. In the meantime, here is a preview of the significant changes and new features:
The only issue I know of is that the vtk.jar is not exported through CMake properly. I need to look at how CMake does it normally to know how to do it. I’ll try and get to it before rc2. https://gitlab.kitware.com/vtk/vtk/issues/17748
Please try what is there now though. My change just makes it possible to Java wrapping of VTK-using libraries, so any code deficiencies are unlikely to be resolved with it.
Right. Can you test that the build-tree vtk.jar file works as-is at least? I suspect some work may be required to package it up as a standalone jar with the native libraries inside the jar as well.
Ah! Now I see what you mean. We typically use it as vtk.jar + a folder of .jnilib anyway (instead of expecting the natives to be packaged within the jar). So I think that will work. Is there a proper build process documented for the new cmake system? Curious if the same cmake flags I had to set before would be appropriate.
@ben.boeckel usually we bundle the native lib in a different jar. Also in the old build process there was an effort to remove any version number in the lib name along with trying to ensure consistent extension across platforms (.dll, .so => .jnilib) Since I’m a bit rusty don’t take my words for it.
OK that looks good - I can try to see if I need to update my scripts today. We make a few special patches to expose a few additional C methods to Java, so I’ll see what I can do.
jnilib is how shared libs get generated on a mac - although I think dylib will also work. Whatever you were doing before was fine
Quick question as I look through the cmake options - it looks like iOS build and BUILD_SHARED_LIBS are mutually exclusive? I have to do the iOS in a separate build?
And also - we used to be able to specify the JOGL_GLUE and JOGL_LIB parameters for specifying which JOGL jars we are using - but I don’t see that as an option. Any ideas?
