[vtk-developers] CMake fails with build type "None" on Ubuntu 18.04

[Elvis Stansvik]

Den fre 11 jan. 2019 kl 21:28 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Fri, Jan 11, 2019 at 20:30:38 +0100, Elvis Stansvik wrote:
> > cmake \
> >     -DCMAKE_INSTALL_PREFIX=/opt/VTK9 \
> >     -DCMAKE_INSTALL_RPATH=/opt/VTK9/lib \
>
> This should now be:
>
> >     -DVTK_Group_Qt=ON \
>
>     VTK_GROUP_ENABLE_Qt=YES
>
> >     -DVTK_QT_VERSION=5 \
>
> Unnecessary; Qt4 is no longer supported.
>
> >     -DVTK_Group_Imaging=ON \
> >     -DVTK_Group_Views=ON \
>
>     VTK_GROUP_ENABLE_Imaging=YES
>     VTK_GROUP_ENABLE_Views=YES
>
> >     -DModule_vtkRenderingFreeTypeFontConfig=ON \
>
>     VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES
>
> >     -DVTK_WRAP_PYTHON=ON \
> >     -DVTK_PYTHON_VERSION=3 \
> >     -DPYTHON_EXECUTABLE=/usr/bin/python3 \
> >     -DPYTHON_INCLUDE_DIR=/usr/include/python3.6 \
> >     -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython3.6m.so \
>
> I'd try not setting these; `FindPython3` should Just Work™ now.
>
> >     -DBUILD_TESTING=OFF \
>
>     VTK_BUILD_TESTING=OFF
>
> >     -DVTK_USE_SYSTEM_LIBRARIES=ON \
>
>     VTK_USE_EXTERNAL=ON
>
> >     -DVTK_USE_SYSTEM_LIBPROJ4=OFF \
> >     -DVTK_USE_SYSTEM_GL2PS=OFF \
> >     -DVTK_USE_SYSTEM_LIBHARU=OFF \
> >     -DVTK_USE_SYSTEM_GLEW=OFF \
> >     -DVTK_USE_SYSTEM_DOUBLECONVERSION=OFF \
>
>     VTK_MODULE_USE_EXTERNAL_VTK_libproj4=ON
>     VTK_MODULE_USE_EXTERNAL_VTK_gl2ps=ON
>     VTK_MODULE_USE_EXTERNAL_VTK_libharu=ON
>     VTK_MODULE_USE_EXTERNAL_VTK_glew=ON
>     VTK_MODULE_USE_EXTERNAL_VTK_doubleconversion=ON
>
> Though looking, I see that these also need the `::` -> `_`
> transformation done first. MR up in a bit.

Thanks a lot of assembling these porting hints. Much appreciated.

>
> > Trying the same with current master (I know some stuff in the above
> > CMake line, like the *USE_SYSTEM* is not applicable anymore, but bear
> > with me), I get:
> >
> > .
> > .
> > .
> > -- Looking for SO_REUSEADDR - found
> > CMake Error at ThirdParty/eigen/vtkeigen/CMakeLists.txt:28 (message):
> >   Unknown build type "None".  Allowed values are Debug, Release,
> >   RelWithDebInfo (case-insensitive).
> >
> > This is due to a check in eigen's CMakeLists.txt which does not
> > include "None" as a valid type.
> >
> > (Side note: This check is, rightfully IMHO, patched away by e.g. the
> > Ubuntu package for eigen3, allowing it to build with build type
> > "None", which is typically used for Debian packages).
> >
> > But, I was just going to ask: Since I could successfully build VTK
> > master using build type "None" earlier, but not now after the new
> > module system was merged, something must have changed causing the
> > eigen3 CMakeLists.txt being parsed while previously it was not
> > (because eigen3 has had that check for a long time).
>
> I probably missed nop-ing out a section of CMake. The code to neuter is
> here:
>
>     https://gitlab.kitware.com/third-party/eigen/blob/for/vtk/CMakeLists.txt#L24

Yep, I know I can fix it by just removing that check (that's what the
Debian package does:
https://salsa.debian.org/science-team/eigen3/blob/master/debian/patches/02_remove_buildtype_check.patch).

I was just wondering how come the old build I did worked? Why didn't
it come across those same lines and bail out?

>
> > I have the full build log for the previously successful build if
> > that's of interest.
> >
> > I have libeigen3-dev installed. But has something changed so that some
> > VTK module now requires the internal eigen3? Looking at e.g.
> > Filters/Statistics, it PRIVATE_DEPENDS on eigen3, which I guess means
> > it needs the internal one? But it seems to have needed that previously
> > too.. Did something change in how this is handled?
>
> No, it just needs the eigen3 module which can be provided by VTK itself
> or by finding another version.
>
> > Calling for Ben's expertise here again I guess :)
> >
> > FWIW, in my own build log from the successful build, I can see for example:
> >
> >    -I/buildbot/b-vtk9/build/ThirdParty/eigen -I/usr/include/eigen3
> >
> > so it was pointing to both the internal and the system-wide one.
> >
> > Perhaps the old build system way was broken, and I was just lucky this worked?
>
> It needed to point internally to get the `vtk_eigen` header (which
> should always be used).

Ah yes, of course. So nothing funny about those two flags coexisting.

Elvis

>
> --Ben