Don't use vendored copies

[isuruf]

Existing conda-forge packages

• glew
• libogg/libtheora
• proj4
• netcdf
• netcdf-cxx4
• lz4

To be packaged

• exodusII
• gl2ps ( Package gl2ps staged-recipes#5857 )
• libharu ( Package libharu staged-recipes#5855 )
• alglib ( Package alglib staged-recipes#5856 )
• verdict

[marcelotrevisani]

Sorry, but what do you mean by vendored copies?

I can help you with that, I'm already requesting some recipes in conda forge

[isuruf]

I mean the source code of these thirdparty libraries are in the vtk sources and unless told to use system libraries, the copy inside vtk sources is compiled.
We need to use the already compiled conda packages instead.

[jakirkham]

Thanks for looking into this, @isuruf.

Indeed we should fix this. Probably cuts down build time too. Also would expect it reduces maintenance burden.

Seems like the first step would be to start using the conda-forge provided packages. The rest can get new issues at staged-recipes.

Side note: By oggtheora are they referring to libtheora (which requires libogg)? Because those do exist as well. If that's not what they mean, not totally sure what they are referring to.

[jakirkham]

Would add using hdf5 on Windows, which is not currently done. Has been Unix only since commit ( 05e291a ). Guessing that is only because hdf5 on Windows did not exist at the time. Though @Korijn probably knows better.

[jakirkham]

Side note: By oggtheora are they referring to libtheora (which requires libogg)? Because those do exist as well. If that's not what they mean, not totally sure what they are referring to.

After looking at the source code, this appears to be what they mean.

[jakirkham]

So @looooo's PR ( #57 ) addresses netcdf and lz4. Have checked those off the list.

[jakirkham]

Looks like by oggtheora, they just mean libogg and not libtheora (though they will add the latter soon). PR ( #60 ) should take care of this requirement.

Edit: Appears headers from libtheora are already needed. Just the third party vendored code has either not been added or not separated from libogg.

[Korijn]

FYI my previous work towards this goal: #2

[jakirkham]

The naming of PROJ.4 has gone back and forth from proj.4 to proj4 a couple of times. As there was a 5.0.0 update recently, there is also some question as to whether it should be renamed again. We might want to hold off on depending on this until that gets resolved.

xref: conda-forge/proj.4-feedstock#12

[Korijn]

To respond to the comment on hdf5 for windows, here's my comment on that from #2:

"hdf5 package cannot be detected by VTK's CMake on Windows"

[jakirkham]

Thanks @Korijn. Read that from the other thread. :)

FWIW it now seems to detect HDF5 on Windows. That's from the build recently deployed. So if you are using Windows, would be good to know if that works well or not. ;)

[jakirkham]

Also there is now a VTK_USE_SYSTEM_SQLITE based on searching the VTK codebase recently. Not sure if that is in a release yet. Anyways something we might explore.

ref: https://gitlab.kitware.com/vtk/vtk/commit/89078faee792eccefce99b0f1e39993f91ca84cb

[jakirkham]

Looked into some of the non-packaged things. Getting source code for Exodus II and VERDICT doesn't appear to be straightforward. The former am not sure where to download from. The latter requires a login. The other two, libharu and ALGLIB, have easily accessible source code.

[Korijn]

By the way, if you want to reduce build time, this made quite a difference for our custom builds:

-DVTK_LEGACY_REMOVE:BOOL=ON

[xylar]

Based on 9.0.0.rc1, the list of libraries that is being vendored is different but several used by vtk are not on conda-forge. These are (near as I can tell):

• libharu being addressed in DEV: Switch from vendored to conda-forge libharu #111
• diy2
• zfp
• dmf2
• dmf3
• pegtl
• kissfft

All other vendored libraries should hopefully be removed in the dev version in #110 and in master as soon as we have a release.

[xylar]

The required libharu isn't a released version, so one step forward, one step back on that one:
https://gitlab.kitware.com/vtk/vtk/-/blob/v9.0.0/ThirdParty/libharu/CMakeLists.txt#L8-11

[isuruf]

Looks like other packagers use these patches in their libharu packages.

[xylar]

We could patch with those but it won't help in vtk because cmake is looking for a non-existent v2.4.0.

[xylar]

FWIW, I added those patches: conda-forge/libharu-feedstock#1