DEV: Update to 9.0.0.rc1

[xylar]

A test build of 9.0.0.rc1. If all goes well, we will merge to a dev branch (needs to be created) and build for a vtk_dev label (see conda_build_config.yml).

The build has been updated largely following (because CDAT has been using a commit close to the current master): https://github.com/CDAT/conda-recipes/blob/master/vtk-cdat/build.sh

Checklist

• [x] Used a fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

closes #90

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xylar]

@conda-forge-admin, please rerender

[xylar]

@conda-forge-admin, please rerender

[xylar]

@muryanto1, I know you are doing local testing of this version of VTK. Please feel free to make suggestions of changes I should make here based on what you find. If you want, you can make pull requests to my branch but it might be easier to just suggest changes and I'll make them.

[xylar]

I opened an issue about the failing python 3.6 builds.

[xylar]

@conda-forge-admin, please rerender

[jschueller]

for the python3 detection you can try what I did in the paraview feedstock:

-DPython3_FIND_STRATEGY=LOCATION \
  -DPython3_ROOT_DIR=${PREFIX} \

[xylar]

@jschueller, thanks! I'll try that.

[xylar]

@jschueller, no luck there. I'm getting:

-- Could NOT find Python2 (missing: Python2_LIBRARIES Python2_INCLUDE_DIRS Development) (Required is at least version "2.6")
CMake Error at CMake/vtkModule.cmake:4112 (message):
  Could not find the Python2 external dependency.
Call Stack (most recent call first):
  Utilities/Python/CMakeLists.txt:33 (vtk_module_find_package)

For reference, here's the diff of the local changes I made:

--- a/recipe/build.sh
+++ b/recipe/build.sh
@@ -6,23 +6,6 @@ cd build || exit
 BUILD_CONFIG=Release
 OSNAME=$(uname)

-# Use bash "Remove Largest Suffix Pattern" to get rid of all but major version number
-PYTHON_MAJOR_VERSION=${PY_VER%%.*}
-
-# These will help cmake find the right python
-PYTHON_H_FILE=$(find "$PREFIX" -name Python.h -type f)
-PYTHON_INCLUDE_DIR=$(dirname "${PYTHON_H_FILE}")
-if [ "${OSNAME}" == Darwin ]; then
-    PYTHON_LIBRARY=$(find "$PREFIX/lib" -regex '.*libpython.*\..*\.dylib$')
-elif [ "${OSNAME}" == Linux ]; then
-    PYTHON_LIBRARY=$(find "$PREFIX/lib" -regex '.*libpython.*\..*\.so$')
-fi
-PYTHON_INCLUDE_PARAMETER_NAME="Python${PYTHON_MAJOR_VERSION}_INCLUDE_DIR"
-PYTHON_LIBRARY_PARAMETER_NAME="Python${PYTHON_MAJOR_VERSION}_LIBRARY_RELEASE"
-if [ "${OSNAME}" == Darwin ]; then
-    CONDA_BUILD_SYSROOT=/opt/MacOSX10.9.sdk
-fi
-
 VTK_ARGS=()

 if [ -f "$PREFIX/lib/libOSMesa32${SHLIB_EXT}" ]; then
@@ -77,9 +60,10 @@ cmake .. -G "Ninja" \
     -DVTK_LEGACY_SILENT:BOOL=OFF \
     -DVTK_HAS_FEENABLEEXCEPT:BOOL=OFF \
     -DVTK_WRAP_PYTHON:BOOL=ON \
-    -DVTK_PYTHON_VERSION:STRING="${PYTHON_MAJOR_VERSION}" \
-    "-D${PYTHON_INCLUDE_PARAMETER_NAME}:PATH=${PYTHON_INCLUDE_DIR}" \
-    "-D${PYTHON_LIBRARY_PARAMETER_NAME}:FILEPATH=${PYTHON_LIBRARY}" \
+    -DPython2_FIND_STRATEGY=LOCATION \
+    -DPython2_ROOT_DIR=${PREFIX} \
+    -DPython3_FIND_STRATEGY=LOCATION \
+    -DPython3_ROOT_DIR=${PREFIX} \
     -DVTK_MODULE_ENABLE_VTK_PythonInterpreter:STRING=NO \
     -DVTK_MODULE_ENABLE_VTK_RenderingFreeType:STRING=YES \
     -DVTK_MODULE_ENABLE_VTK_RenderingMatplotlib:STRING=YES \

[xylar]

In my local python 3.6 build, I'm seeing success when I still set -DVTK_PYTHON_VERSION:STRING="${PYTHON_MAJOR_VERSION}", so I'm going to give that a try.

[xylar]

@muryanto1, I rebased this branch onto the current master. You should be able to rebase your work onto this branch (though my most recent commits might conflict with what you're trying).

[xylar]

Okay, I think we might have OSX and linux working now!!! Thanks @jschueller for getting us most of the way there with your suggestion.

@conda-forge/vtk, anyone have experience with Windows and want to try to figure out why that's failing?

[xylar]

I created the dev branch to merge this to if we can get the builds to succeed.

[xylar]

@conda-forge/vtk, I've made some progress on the Windows builds. Some are failing because of limited connections to gitlab.kitware.com, but one (python 3.8) made it through to testing only to give:

import: 'vtk'
Traceback (most recent call last):
  File "D:\bld\vtk_1584616067609\test_tmp\run_test.py", line 12, in <module>
    import vtk
ModuleNotFoundError: No module named 'vtk'

A anyone able to take a look?

[jschueller]

you can stop the annoying data downloads with

-DVTK_DATA_EXCLUDE_FROM_ALL=ON

[jschueller]

I guess the vtk python module is not found as you install into LIBRARY_PREFIX. Now everything has to be a subdir of %PREFIX% so for pv I had to use:

-DCMAKE_INSTALL_LIBDIR="Library/lib" ^
    -DCMAKE_INSTALL_BINDIR="Library/bin" ^
    -DCMAKE_INSTALL_INCLUDEDIR="Library/include" ^
    -DCMAKE_INSTALL_DATAROOTDIR="Library/share" ^
    -DCMAKE_INSTALL_PREFIX="%PREFIX%" ^
  -DPARAVIEW_PYTHON_SITE_PACKAGES_SUFFIX="Lib/site-packages" ^

see https://github.com/conda-forge/paraview-feedstock/blob/master/recipe/bld.bat

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• License is not an SPDX identifier (or Other) nor an SPDX license expression.

[xylar]

@jschueller, I can't tell you how much I appreciate both suggestions! Let's see how it goes.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xylar]

Everything built!!!

[xylar]

Since this is just going to the vtk_dev label, I don't feel too concerned about just merging. @muryanto1, could you approve before I do that?

Anyone else that wants to review, please do so in the next 24 hours (or at least indicate your interest). I'll merge at this time tomorrow.

[xylar]

@muryanto1, just to let you know, I just rebased this onto #103 to include tk support here as well. We'll merge #103 first and then this (though they're going to different branches so I guess it doesn't matter all that much).

[xylar]

@jsbronder, we're having trouble with TCL/TK here. If you'd like to have it available in 9.0.0, I'd appreciate any help you can offer in getting it working here. If it's beyond your expertise, just let me know.

[xylar]

It looks like tk and mesalib is maybe either or (at least of OSX). That makes sense to me -- no need for tk when you're not actually displaying. I'll make the update.

I'm not sure why the Windows build can't find TCL. I've tried installing tk locally on Windows and all the libs and includes are exactly where you'd expect them to be. I'm not good at cmake but from what I can gather, it should easily be able to find it, especially given that it can find tclsh.exe. I'm baffled...

[xylar]

@jsbronder, I don't want to ask too much of you but you've been extremely helpful so far. Any advice on getting cmake to find the TCL libraries in the Windows build? They're currently running but I expect them to fail soon.

[xylar]

@conda-forge-admin, please rerender

[xylar]

I think I'm just going to disable tk again for Windows to get this thing over and done with.

[xylar]

@conda-forge-admin, please rerender

[jsbronder]

The OS X errors from https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=133483&view=logs&j=385a3385-ae8b-54d1-9abe-3c614f74cb73&t=16b4927f-322a-5216-6fdf-583331d592a6&l=4968 look more like they're due to -DVTK_USE_X:BOOL=OFF as it's complaining about missing xlib functions. Which is weird that you'd only expose that by toggling OSMesa (which is just another rendering backend and should be completely independent of the tk backend).

The last windows error is failing here, https://gitlab.kitware.com/vtk/vtk/-/blob/master/CMake/FindTCL.cmake#L91. Does your windows machine have a tcl library that would match one of the paths being searched there?

Sadly it's tough for me to do much here as I don't (and haven't for 15+ years) have access to either OS.

[xylar]

Does your windows machine have a tcl library that would match one of the paths being searched there?

Yeah, I've installed tk=8.6 (the conda-forge pin) locally on my Windows virtual box and the tcl libraries and includes are also there as expected in the environment under Library/lib and Library/include.

Sadly it's tough for me to do much here as I don't (and haven't for 15+ years) have access to either OS.

Yep, I use Linux but have to have a Window virtual box and I use MacInCloud to test OSX when I have to. I also have no expertise on either OS, so I'm kind of fumbling in the dark here.

Only working on VTK because it's a bottleneck way upstream in a project I'm involved in that involves CDAT...

[xylar]

The OS X errors ... look more like they're due to -DVTK_USE_X:BOOL=OFF as it's complaining about missing xlib functions.

Would your suggestion be to not turn of X even with mesalib?

[xylar]

@conda-forge-admin, please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do.

[jsbronder]

The OS X errors ... look more like they're due to -DVTK_USE_X:BOOL=OFF as it's complaining about missing xlib functions.

Would your suggestion be to not turn of X even with mesalib?

I don't know. Is it acceptable to leave tk off until someone with expertise with OS X wants to contribute the fix to get it to work? The code that's failing shouldn't even be getting seen by the compiler. That is, it looks like this:

#if defined(VTK_USE_COCOA)
// bunch of stuff
#else
// failing code is here

So if the -DVTK_USE_COCOA took, it shouldn't even be getting seen. That looks like a build system bug and would be tough to debug without messing with the CMake on an OS X machine.

[xylar]

Thanks @jsbronder. It sounds like something to post an issue about on the VTK repo, but I want to get a test build going so I'll just disable TK in combination with OSMESA for now and call it good.