vtk-8.2.0-rc2 problem building wheels

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

vtk-8.2.0-rc2 problem building wheels

Prabhu Ramachandran-3

Hi all,

Here is hopefully the last of the issues I am running into, I just tried to create wheels for 8.2.0-rc2 and have the following problem. 

First for some background.  Some of the VTK Python libraries seem to link to the PYTHON_LIBRARY, for the wheels, we do not do this.  JC pointed this out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1

Basically, if we build wheels linking to the libpython* the wheel may not work on Ubuntu/Debian which would be sad.

In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.  This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.  Anyway, when I try to build the wheels now on MacOS I get this error:

Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib
FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib
: && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup  -compatibility_version 1.0.0 -current_version 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name @rpath/libvtkPythonInterpreter-8.2.1.dylib Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o  -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && :
ld: file too small (length=0) file 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY entry blank.  This means that the libvtkPythonInterpreter-8.2.1.dylib does indeed link to the libpythonx.y.dylib. 

However, I do notice that the other libvtk*Python*8.2.1.dylib do not link to libpython.  So libvtkPythonInterpreter is the only one linking to libpython. So I think maybe if a user never uses the libvtkPythonInterpreter or if that is never explicitly imported or linked to in any Python code, we may be fine with these wheels.  Also I see that none of the Python extension modules, i.e. all the vtk*Python.so do not link to libpython or to libvtkPythonInterpreter.

Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank?

I would appreciate your thoughts on this matter. Thanks!

cheers,

Prabhu


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sreekanth Arikatla

On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

Here is hopefully the last of the issues I am running into, I just tried to create wheels for 8.2.0-rc2 and have the following problem. 

First for some background.  Some of the VTK Python libraries seem to link to the PYTHON_LIBRARY, for the wheels, we do not do this.  JC pointed this out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1

Basically, if we build wheels linking to the libpython* the wheel may not work on Ubuntu/Debian which would be sad.

In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.  This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.  Anyway, when I try to build the wheels now on MacOS I get this error:

Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib
FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib
: && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup  -compatibility_version 1.0.0 -current_version 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name @rpath/libvtkPythonInterpreter-8.2.1.dylib Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o  -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && :
ld: file too small (length=0) file 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY entry blank.  This means that the libvtkPythonInterpreter-8.2.1.dylib does indeed link to the libpythonx.y.dylib. 

However, I do notice that the other libvtk*Python*8.2.1.dylib do not link to libpython.  So libvtkPythonInterpreter is the only one linking to libpython. So I think maybe if a user never uses the libvtkPythonInterpreter or if that is never explicitly imported or linked to in any Python code, we may be fine with these wheels.  Also I see that none of the Python extension modules, i.e. all the vtk*Python.so do not link to libpython or to libvtkPythonInterpreter.

Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank?

I would appreciate your thoughts on this matter. Thanks!

cheers,

Prabhu

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers



--
Sreekanth Arikatla, Ph.D.,
Senior R&D Engineer,
Kitware, Inc., Carrboro, NC.


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sreekanth Arikatla
Please ignore the previous email. I sent it by mistake.

On Tue, Nov 27, 2018 at 3:59 PM Sreekanth Arikatla <[hidden email]> wrote:

On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

Here is hopefully the last of the issues I am running into, I just tried to create wheels for 8.2.0-rc2 and have the following problem. 

First for some background.  Some of the VTK Python libraries seem to link to the PYTHON_LIBRARY, for the wheels, we do not do this.  JC pointed this out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1

Basically, if we build wheels linking to the libpython* the wheel may not work on Ubuntu/Debian which would be sad.

In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.  This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.  Anyway, when I try to build the wheels now on MacOS I get this error:

Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib
FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib
: && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup  -compatibility_version 1.0.0 -current_version 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name @rpath/libvtkPythonInterpreter-8.2.1.dylib Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o  -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && :
ld: file too small (length=0) file 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY entry blank.  This means that the libvtkPythonInterpreter-8.2.1.dylib does indeed link to the libpythonx.y.dylib. 

However, I do notice that the other libvtk*Python*8.2.1.dylib do not link to libpython.  So libvtkPythonInterpreter is the only one linking to libpython. So I think maybe if a user never uses the libvtkPythonInterpreter or if that is never explicitly imported or linked to in any Python code, we may be fine with these wheels.  Also I see that none of the Python extension modules, i.e. all the vtk*Python.so do not link to libpython or to libvtkPythonInterpreter.

Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank?

I would appreciate your thoughts on this matter. Thanks!

cheers,

Prabhu

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers



--
Sreekanth Arikatla, Ph.D.,
Senior R&D Engineer,
Kitware, Inc., Carrboro, NC.



--
Sreekanth Arikatla, Ph.D.,
Senior R&D Engineer,
Kitware, Inc., Carrboro, NC.


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Jean-Christophe Fillion-Robin-2
In reply to this post by Prabhu Ramachandran-3
Hi Prabhu,

> In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.  This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.

This was done to ensure no library was strongly linking against python library. And if it did, the error message would be more explicit. It was working because the library was always weakly linked in older version of VTK.


> Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank?

It looks like introducing an option to conditionally build vtkPythonInterpreter would address the issue here.

@Ben: What do you think ?

Jc







On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran <[hidden email]> wrote:

Hi all,

Here is hopefully the last of the issues I am running into, I just tried to create wheels for 8.2.0-rc2 and have the following problem. 

First for some background.  Some of the VTK Python libraries seem to link to the PYTHON_LIBRARY, for the wheels, we do not do this.  JC pointed this out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1

Basically, if we build wheels linking to the libpython* the wheel may not work on Ubuntu/Debian which would be sad.

In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.  This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.  Anyway, when I try to build the wheels now on MacOS I get this error:

Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib
FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib
: && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup  -compatibility_version 1.0.0 -current_version 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name @rpath/libvtkPythonInterpreter-8.2.1.dylib Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o  -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && :
ld: file too small (length=0) file 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY entry blank.  This means that the libvtkPythonInterpreter-8.2.1.dylib does indeed link to the libpythonx.y.dylib. 

However, I do notice that the other libvtk*Python*8.2.1.dylib do not link to libpython.  So libvtkPythonInterpreter is the only one linking to libpython. So I think maybe if a user never uses the libvtkPythonInterpreter or if that is never explicitly imported or linked to in any Python code, we may be fine with these wheels.  Also I see that none of the Python extension modules, i.e. all the vtk*Python.so do not link to libpython or to libvtkPythonInterpreter.

Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank?

I would appreciate your thoughts on this matter. Thanks!

cheers,

Prabhu


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
On Tue, Nov 27, 2018 at 19:02:14 -0500, Jean-Christophe Fillion-Robin wrote:
> > Should I just ignore the libvtkPythonInterpreter and leave the
> > PYTHON_LIBRARY field blank?

It being blank will cause `find_library` to try and find it itself. I
think the error is that now an empty linker script is not valid, but I'm
not sure. Is it possible to use an older compiler/linker to make the
wheels?

> It looks like introducing an option to conditionally build
> vtkPythonInterpreter would address the issue here.
>
> @Ben: What do you think ?

How would this work? If it is disabled, `vtkWrappingPythonCore` (a
dependency of all wrapped Python modules) and `vtkRenderingMatplotlib`
can't be built.

For the record, the new module system's way of doing this is here:

    https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Utilities/Python/CMakeLists.txt#L118

Basically, the `VTK::Python` module contains the library for
executables, but is just the magic flags to ignore the missing symbols
when linking libraries. So, it should "just work", but it does require
3.13+ for `target_link_options` (without it, direct linking is used). It
can't really be backported because the old module system is quite
allergic to CMake's target stuff (since it was designed basically as the
same thing, but predate's CMake's logic).

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Prabhu Ramachandran-3
On 11/28/18 11:00 AM, Ben Boeckel wrote:
On Tue, Nov 27, 2018 at 19:02:14 -0500, Jean-Christophe Fillion-Robin wrote:
Should I just ignore the libvtkPythonInterpreter and leave the
PYTHON_LIBRARY field blank?
It being blank will cause `find_library` to try and find it itself. I
think the error is that now an empty linker script is not valid, but I'm
not sure. Is it possible to use an older compiler/linker to make the
wheels?

Unfortunately, that is a pain, so no, I don't think it would be convenient or meaningful to expect an older compiler/linker.


      
It looks like introducing an option to conditionally build
vtkPythonInterpreter would address the issue here.

@Ben: What do you think ?
How would this work? If it is disabled, `vtkWrappingPythonCore` (a
dependency of all wrapped Python modules) and `vtkRenderingMatplotlib`
can't be built.

Does vtkWrappingPythonCore depend on vtkPythonInterpreter?  vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter.  The wheels by default do not seem to enable vtkRenderingMatplotlib although I am not sure if it should be added by default in the future, in which case this is a more serious issue.

For the record, the new module system's way of doing this is here:

    https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Utilities/Python/CMakeLists.txt#L118

Basically, the `VTK::Python` module contains the library for
executables, but is just the magic flags to ignore the missing symbols
when linking libraries. So, it should "just work", but it does require
3.13+ for `target_link_options` (without it, direct linking is used). It
can't really be backported because the old module system is quite
allergic to CMake's target stuff (since it was designed basically as the
same thing, but predate's CMake's logic).

I think requiring a newer CMake is fairly reasonable if that will solve the problem unless I am missing something obvious here (which is very likely).

cheers,

Prabhu



--Ben



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote:
> Does vtkWrappingPythonCore depend on vtkPythonInterpreter? 
> vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter. 

My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious.
Removing that dependency and then disabling the module should work.

> The wheels by default do not seem to enable vtkRenderingMatplotlib although I am
> not sure if it should be added by default in the future, in which case this is a
> more serious issue.

IMO, distribution builds should try to enable *everything* so there
isn't a question of "what do I have today?" when doing `import vtk`.
Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to
not have the linking problem.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
I think the dependency comes in for the sake of VTK's python tests, as those call vtkpython.
Prabu can you try this and see if you get a pip worthy build out of it?
Note you must set these two configure flags to get it to compile.
BUILD_TESTING:BOOL=OFF
VTK_ENABLE_VTKPYTHON:BOOL=OFF
Longer term we should do a clean break by trying to move the bits of VTKPYTHON that remain in Wrapping/PythonCore to Utilities/PythonInterpretter and making sure the python tests agree.

Regarding matplotlib, for the moment just leave it off in the wheels. Ben's point of wrapping everything and the corrolary that VTK's modules should be atomic (options don't change the library internals) is an important goal that we won't fix in 8.2. We made strides in VTK 6.0 and will get much closer in 9.0, hopefully packagers and all consumers of VTK will have a better time of it after 9.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909



On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers <[hidden email]> wrote:
On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote:
> Does vtkWrappingPythonCore depend on vtkPythonInterpreter? 
> vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter. 

My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious.
Removing that dependency and then disabling the module should work.

> The wheels by default do not seem to enable vtkRenderingMatplotlib although I am
> not sure if it should be added by default in the future, in which case this is a
> more serious issue.

IMO, distribution builds should try to enable *everything* so there
isn't a question of "what do I have today?" when doing `import vtk`.
Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to
not have the linking problem.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
[hidden email] [hidden email] FYI the python path improvments that you all did appear to have unintended consequences on wheel building for VTK.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909


On Thu, Dec 6, 2018 at 11:48 AM David E DeMarle <[hidden email]> wrote:
I think the dependency comes in for the sake of VTK's python tests, as those call vtkpython.
Prabu can you try this and see if you get a pip worthy build out of it?
Note you must set these two configure flags to get it to compile.
BUILD_TESTING:BOOL=OFF
VTK_ENABLE_VTKPYTHON:BOOL=OFF
Longer term we should do a clean break by trying to move the bits of VTKPYTHON that remain in Wrapping/PythonCore to Utilities/PythonInterpretter and making sure the python tests agree.

Regarding matplotlib, for the moment just leave it off in the wheels. Ben's point of wrapping everything and the corrolary that VTK's modules should be atomic (options don't change the library internals) is an important goal that we won't fix in 8.2. We made strides in VTK 6.0 and will get much closer in 9.0, hopefully packagers and all consumers of VTK will have a better time of it after 9.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909



On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers <[hidden email]> wrote:
On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote:
> Does vtkWrappingPythonCore depend on vtkPythonInterpreter? 
> vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter. 

My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious.
Removing that dependency and then disabling the module should work.

> The wheels by default do not seem to enable vtkRenderingMatplotlib although I am
> not sure if it should be added by default in the future, in which case this is a
> more serious issue.

IMO, distribution builds should try to enable *everything* so there
isn't a question of "what do I have today?" when doing `import vtk`.
Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to
not have the linking problem.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
In reply to this post by Sebastien Jourdain via vtk-developers
> VTK_ENABLE_VTKPYTHON:BOOL=OFF

As a side note, would it make sense to renamed this option to VTK_BUILD_VTKPYTHON_EXECUTABLE (or VTK_ENABLE_VTKPYTHON_EXECUTABLE)

> distribution builds should try to enable *everything*


In that context, I don't think it makes sense to build VTK own python interpreter. Ideally, it should be possible to run VTK test with or without it.

I also envision we could have a "vtk-openvr" python module but it wouldn't be available by default when installing vtk wheel. To support this level of "modularity" , we would continue building part of VTK independently (for example, we can already do this with the VTKOpenVR module)





On Thu, Dec 6, 2018 at 11:48 AM David E DeMarle <[hidden email]> wrote:
I think the dependency comes in for the sake of VTK's python tests, as those call vtkpython.
Prabu can you try this and see if you get a pip worthy build out of it?
Note you must set these two configure flags to get it to compile.
BUILD_TESTING:BOOL=OFF
VTK_ENABLE_VTKPYTHON:BOOL=OFF
Longer term we should do a clean break by trying to move the bits of VTKPYTHON that remain in Wrapping/PythonCore to Utilities/PythonInterpretter and making sure the python tests agree.

Regarding matplotlib, for the moment just leave it off in the wheels. Ben's point of wrapping everything and the corrolary that VTK's modules should be atomic (options don't change the library internals) is an important goal that we won't fix in 8.2. We made strides in VTK 6.0 and will get much closer in 9.0, hopefully packagers and all consumers of VTK will have a better time of it after 9.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909



On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers <[hidden email]> wrote:
On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote:
> Does vtkWrappingPythonCore depend on vtkPythonInterpreter? 
> vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter. 

My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious.
Removing that dependency and then disabling the module should work.

> The wheels by default do not seem to enable vtkRenderingMatplotlib although I am
> not sure if it should be added by default in the future, in which case this is a
> more serious issue.

IMO, distribution builds should try to enable *everything* so there
isn't a question of "what do I have today?" when doing `import vtk`.
Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to
not have the linking problem.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk-8.2.0-rc2 problem building wheels

Sebastien Jourdain via vtk-developers
On Fri, Dec 07, 2018 at 17:00:20 -0500, Jean-Christophe Fillion-Robin wrote:
> > distribution builds should try to enable *everything*
>
> In that context, I don't think it makes sense to build VTK own python
> interpreter. Ideally, it should be possible to run VTK test with or without
> it.

Yes, it is very odd that we've always built our own interpreter. IMO,
it'd be better to just set PYTHONPATH on the test suite and use a
standard Python executable.

> I also envision we could have a "vtk-openvr" python module but it wouldn't
> be available by default when installing vtk wheel. To support this level of
> "modularity" , we would continue building part of VTK independently (for
> example, we can already do this with the VTKOpenVR module)

The new module system doesn't support this at the moment (i.e., the
`find_package(VTK)` code has been ripped out of the OpenVR module). The
problem with this is that if a module can be built inside and outside of
VTK, dependent projects cannot know whether to do `find_package(VTK
COMPONENTS RenderingOpenVR)` or `find_package(VTKOpenVR)`.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers