1. 30 Nov, 2017 1 commit
  2. 14 Nov, 2017 2 commits
    • Utkarsh Ayachit's avatar
      Clean Python related CMake variables. · b94049f6
      Utkarsh Ayachit authored
      This change removes `VTK_INSTALL_PYTHON_MODULE_DIR` and
      `VTK_BUILD_PYTHON_MODULE_DIR` cmake variables. These were cache
      variabels and they were force set using Python version number the first
      time CMake was run. This has the issue of leaving an obsolete value if
      Python version was changed in CMake config after the first cmake pass.
      
      Secondly, the two variables complicated module path setup logic since
      build and install directory structure for Python modules could
      potentially be different.
      
      Simplified this as follows:
      
      `VTK_PYTHON_SITE_PACKAGES_SUFFIX` is a new CMake variable available
      for users to set to the "site-packges" suffix to use for build and
      install trees. This is non-cache variable and hence we we update it
      when Python version is changed in subsequent cmake configurations
      without issues (unless explicitly overridden).
      
      The build and install directories for Python modules are set as
      `${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${VTK_PYTHON_SITE_PACKAGES_SUFFIX}`,
      `${VTK_INSTALL_LIBRARY_DIR}/${VTK_PYTHON_SITE_PACKAGES_SUFFIX}`
      respectively. Thus, we are assured that build and install tree
      structures won't differ. `VTK_BUILD_PYTHON_MODULES_DIR` and
      `VTK_INSTALL_PYTHON_MODULES_DIR` internal cache variable are available
      as shortcuts for these two paths, but we may purge them in future.
      b94049f6
    • Utkarsh Ayachit's avatar
      Cleanup VTK's Python package. · 867d93c2
      Utkarsh Ayachit authored
      VTK's wrapped C++-Python module libraries are built under the
      `VTK_BUILD_PYTHON_MODULE_DIR`. That way, we don't need to add extra
      paths to locate those. Since those are indeed Python module files,
      they should indeed be under the VTK_BUILD_PYTHON_MODULE_DIR.
      
      VTK's Python package is built under the path specified by
      `VTK_BUILD_PYTHON_MODULE_DIR` and installed to
      `VTK_INSTALL_PYTHON_MODULE_DIR`.
      
      Improved defaults for VTK_BUILD_PYTHON_MODULE_DIR and
      VTK_INSTALL_PYTHON_MODULE_DIR. The new defaults avoid having to
      separately deal with python module paths for build and install
      directories.
      867d93c2
  3. 05 May, 2017 1 commit
  4. 16 Jan, 2017 1 commit
    • Michka Popoff's avatar
      ENH: Do not link against libpython when possible · 5668595e
      Michka Popoff authored
      This is similar to what is already done in ITK and SimpleITK.
      
      The new vtkTargetLinkLibrariesWithDynamicLookup.cmake file is slightly modified copy from
      ITK/CMake/itkTargetLinkLibrariesWithDynamicLookup.cmake
      The explanation of what this patch tries to achieve is documented in this file.
      
      A new argument is introduced, called OPTIONAL_PYTHON_LINK.
      When used, the module will be optionally be linked against libpython.
      In the module.cmake files, most vtkPython dependencies were moved to COMPILE_DEPENDS, so that libpython is not added to the target_link_libraries() call.
      
      The vtkPython is explicitely linked against the python libraries, as this is a python executable.
      
      Also, the find_package calls for the PythonLibs were made optional when possible.
      
      The XDMF3 project was not updated, this will need to be done separately if weak linking is wished for that project.
      
      Fixes: #16068
      5668595e
  5. 10 Jan, 2017 1 commit
  6. 15 Dec, 2016 1 commit
  7. 01 Dec, 2016 1 commit
    • David Gobbi's avatar
      Make WRAP_DEPENDS from DEPENDS and PRIVATE_DEPENDS · 98f45e95
      David Gobbi authored
      In VTK 6.1 the PRIVATE_DEPENDS section was added to the module.cmake files,
      in order to reduce linking.  This created a problem for the wrappers that
      went unnoticed at the time: when a VTK interface method takes or return a
      pointer to a VTK object, a simple forward declaration and private linkage
      of the library defining that object is sufficient for C++.  But for the
      wrappers, it is insufficient because the wrappers require the definitions
      of any types that are used as method parameters, otherwise they cannot
      know whether a forward-declared class is derived from vtkObject or not.
      
      For VTK 7.1 the module.cmake files were cleaned up and many dependencies
      were moved from DEPENDS to PRIVATE_DEPENDS.  This cleanup caused the
      bug that was introduced in VTK 6.1 to become apparent, because suddenly
      a whole bunch of methods were not longer wrapped in Java because the
      wrappers could not reliably determine whether forward-declared types
      were derived from vtkObject or not.  Tcl and Python continued to work
      because they are less strict in their type checking.
      98f45e95
  8. 08 Jul, 2016 1 commit
  9. 26 Jun, 2016 1 commit
    • Michka Popoff's avatar
      ENH: Do not link against libpython when possible · 772cc086
      Michka Popoff authored
      This is similar to what is already done in ITK and SimpleITK.
      
      The new vtkTargetLinkLibrariesWithDynamicLookup.cmake file is slightly modified copy from ITK (things have been renamed from ITK to VTK). The explanation of what this patch tries to achieve is documented in this file.
      
      A new argument is introduced, called OPTIONAL_PYTHON_LINK. When used, the module will be optionally be linked against libpython. In the module.cmake files, most vtkPython dependencies were moved to COMPILE_DEPENDS, so that libpython is not added to the target_link_libraries() call.
      
      The vtkPython is explicitely linked against the python libraries, as this is a python executable.
      
      Also, the find_package calls for the PythonLibs were made optional when possible.
      
      This fixes the following bug: http://www.vtk.org/Bug/view.php?id=16068
      772cc086
  10. 15 Mar, 2016 1 commit
    • Utkarsh Ayachit's avatar
      Fix build issues with static builds + Python + kits · 34e28445
      Utkarsh Ayachit authored
      When building statically with Python support and Kits enabled, the
      vtkpython executable was trying to link against ${vtk-module}Python library
      rather than linking the corresponding ${vtk-kit}Python library. This fixes
      that issue. This also ensures that the header generated for initializing
      Python modules uses correct kit-based names.
      
      For this to work properly, we needed to save the KIT information to
      module-config. Hence ${vtk-module}Module.cmake file now has a new variable
      ${vtk-module}_KIT which indicates the Kit that the module belongs to.
      34e28445
  11. 08 Mar, 2016 1 commit
  12. 25 Feb, 2016 1 commit
    • Max Smolens's avatar
      python: Add wrapping of kits when VTK_ENABLE_KITS is ON · 1ebfa5bc
      Max Smolens authored
      
      
      If VTK_ENABLE_KITS is ON, VTK kits and modules that are not associated with any
      kit will be wrapped. The effect is that drastically fewer libraries are created.
      
      Take vtkCommon as an example. When VTK_ENABLE_KITS is OFF, a library is
      generated for each wrapped module:
      
          vtkCommonColorPython27D-x.y.dll
          vtkCommonComputationalGeometryPython27D-x.y.dll
          vtkCommonCorePython27D-x.y.dll
          vtkCommonDataModelPython27D-x.y.dll
          vtkCommonExecutionModelPython27D-x.y.dll
          vtkCommonMathPython27D-x.y.dll
          vtkCommonMiscPython27D-x.y.dll
          vtkCommonSystemPython27D-x.y.dll
          vtkCommonTransformsPython27D-x.y.dll
      
      When VTK_ENABLE_KITS is ON, a single "kit" library is generated:
      
          vtkCommonKitPython27D-x.y.dll
      
      The wrapped kits have the suffix "Kit" to avoid naming conflicts with existing
      libraries like "vtkFilterPython".
      
      As part of this change, the Python wrapping function has been split into two
      functions, one which wraps the code and another which builds the wrapped code.
      The new function is backwards compatible, but to update client code, replace
      calls like:
      
          vtk_add_python_wrapping(${module})
      
      with:
      
          vtk_add_python_wrapping(${module} module_srcs)
          vtk_add_python_wrapping_library(${module} module_srcs ${module})
      
      Additionally, the functions "vtk_wrap_python" and "vtk_add_python_wrapping" have
      been updated to understand a list of modules as input.
      Co-authored-by: Jean-Christophe Fillion-Robin's avatarJean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
      Co-authored-by: Max Smolens's avatarMax Smolens <max.smolens@kitware.com>
      Co-authored-by: Ben Boeckel's avatarBen Boeckel <ben.boeckel@kitware.com>
      1ebfa5bc
  13. 16 Jun, 2015 1 commit
  14. 02 Oct, 2014 1 commit
    • David Gobbi's avatar
      14552: Check python interp and lib versions. · 52a5b977
      David Gobbi authored
      Add a variable to allow the user to choose a version for the python
      interpreter.  Attempt to locate libraries with the same version number.
      Emit a warning if the library version number and the interpreter
      version number do not match.
      
      Change-Id: I0c555c01deb7d6fa9a4f57d65ff5125463de7aef
      52a5b977
  15. 17 Sep, 2013 1 commit
  16. 16 Sep, 2013 1 commit
    • Brad King's avatar
      COMP: Populate VTK wrapping module link interfaces · f986259d
      Brad King authored
      Since commit 6383648d (COMP: Set CMake Policy CMP0022 to NEW,
      2013-09-11) we tell CMake >= 2.8.12 to use the INTERFACE_LINK_LIBRARIES
      property to define the link interface of libraries.  Populate it for VTK
      wrapping libraries by using target_link_libraries with LINK_PUBLIC.
      
      Change-Id: Id8581ea5039e76eab2c6684bf48e6e6cd80da3b9
      f986259d
  17. 03 Sep, 2013 1 commit
    • Ben Boeckel's avatar
      Split Python module initialization function out · 989050fa
      Ben Boeckel authored
      The module initialization function has always been put into the Python
      module itself which is marked as a MODULE in add_library in the VTK
      wrapping macros. CMake disallows linking directly to a MODULE, so if
      something external to the bindings want to use the module initialization
      function, they don't have access to it.
      
      To fix this, the module method is placed in an OBJECT library which can
      be linked against to get access to the init function. In addition, the
      code which loads each class into the module is moved into the PythonD
      library. The Python module itself doesn't use the object library since some
      generators do not support targets with only objects from other targets.
      
      This is mainly intended for use in ParaView so that the Python bindings
      for classes may be used to implement the ClientServer wrappings with the
      Python wrappings instead of generating a second set of bindings.
      
      Change-Id: I8dd2eb672a3b038dedafa79cae271b88fad06082
      989050fa
  18. 15 Aug, 2013 1 commit
    • Dave DeMarle's avatar
      Use cmake install instead of setup.py to install python wrapping. · beae7c64
      Dave DeMarle authored
      Distutils path is not well maintained and from what packagers
      tell me, largely unused. It is also buggy and hard to use.
      Removing it and letting CMake install instead. Doing this will
      properly remove rpath and likely fix other bugs.
      
      Change-Id: I60f375449344bcd8b2b2823c248eb69163026a3a
      beae7c64
  19. 03 Apr, 2013 1 commit
    • Marcus D. Hanwell's avatar
      Added facility to export custom hints for modules · 95d4ca64
      Marcus D. Hanwell authored
      Added ${vtk-module}_WRAP_HINTS as a module specific hints file, to allow
      modules to set a custom wrapping hints file (as external projects such
      as ParaView have done for many years).
      
      Also cleaned up the installation code to ensure the hierarchy and hints
      files are installed when appropriate.
      
      Change-Id: Ie019fab326a3072a33bdc2aaf066180b2fa32eb1
      95d4ca64
  20. 26 Mar, 2013 1 commit
  21. 22 Mar, 2013 2 commits
  22. 20 Feb, 2013 1 commit
    • David Gobbi's avatar
      BUG 13875: Add a separate python module to resolve dependencies. · 146e2f78
      David Gobbi authored
      The dependency of Rendering/Matplotlib on Wrapping/Python was causing
      the latter module to be configured too early.  Wrapping/Python must
      be configured after all wrapped modules or it will not be able to capture
      all of the wrapped modules properly.
      
      The solution is to create a new Python vtk-module that both Wrapping/Python
      and Rendering/Matplotlib can depend on.
      
      Change-Id: I8348fd80147126866dec91488cb0771a7f412636
      146e2f78
  23. 28 Jan, 2013 1 commit
    • Utkarsh Ayachit's avatar
      Adding mechanism to locate Hierarchy.txt file for a module. · 1ae88fb4
      Utkarsh Ayachit authored
      This patch adds a variable to a module-config file that identifies the location
      of the Hierarchy.txt file. Thus projects no longer have to guess the location
      for a Hierarchy.txt file, it is imported when the module's configuration is
      imported.
      
      Note that we are still not installing Hierarchy.txt files for development
      installs, hence the locations for the Hierarchy.txt file in the installed
      module-configs is currently bogus..
      
      Change-Id: Ibaa0324765753f60e5a15e319f2367d75ce7c5c8
      1ae88fb4
  24. 11 Jan, 2013 1 commit
    • Marcus D. Hanwell's avatar
      Check if the PythonD target exists · a55006c1
      Marcus D. Hanwell authored
      This allows for external Python wrapping to work, and also continues to
      work as expected when wrapping VTK modules. The dependency source
      directory was also being added twice (once here, and once with the
      binary directory in CMake/Wrapping.cmake).
      
      Change-Id: Ie33ae695b66655b2b7c424f08c55cb18f25d882e
      a55006c1
  25. 08 Jan, 2013 1 commit
    • Marcus D. Hanwell's avatar
      Put all wrap hierarchy files in VTK_MODULES_DIR · c432ae16
      Marcus D. Hanwell authored
      This allows for much simpler code when wrapping an external VTK module.
      Also just check if the module is wrap hierarchy excluded - the
      <module>_BINARY_DIR will not exist when building against VTK.
      
      Change-Id: Id6e92685239dddab3c4a8911aea4017e349b8942
      c432ae16
  26. 17 Oct, 2012 1 commit
    • Chris Harris's avatar
      Add support for selectively Python wrapping modules · b26e66f9
      Chris Harris authored
      Introduce VTK_WRAP_PYTHON_MODULES variable that can
      be used to explicitly control which modules get
      Python wrapped. At this time no automatic dependency
      support is provided, however, when the concept of
      "private dependencies" is introduced this can be
      addressed.
      
      Change-Id: Ia568a355e41c39bb026ddc649797c06cfa94e27b
      b26e66f9
  27. 28 Aug, 2012 1 commit
  28. 16 Aug, 2012 1 commit
    • Utkarsh Ayachit's avatar
      Adding install rules for Python modules. · f45a2728
      Utkarsh Ayachit authored
      When VTK is told to not use setup.py for installing Python (which is the case
      with applications like ParaView), CMake rules were missing to ensure that the
      python module libraries are installed. This patch adds those rules which are
      used only when VTK_INSTALL_PYTHON_USING_CMAKE is ON.
      
      Change-Id: I88afaae2a08915e02476ac1c1027fba4fc4fe3d4
      f45a2728
  29. 06 Aug, 2012 2 commits
    • Utkarsh Ayachit's avatar
      Fixing code to locate wrapping executables using targets, if possible. · 62510085
      Utkarsh Ayachit authored
      When building projects dependending on VTK, we ran into issues since some
      variables were expected to be declared e.g. VTK_WRAP_PYTHON_INIT_EXE,
      VTK_WRAP_HIERARCHY_EXE. These are unnnecessary since they are imported targets
      and should be used if present. Updated code to use the targets directly if
      found.
      
      Change-Id: I74b5996671e195b02bd65b85b71a2e33bd3ca2da
      62510085
    • Utkarsh Ayachit's avatar
      Fixing code to locate wrapping executables using targets, if possible. · 5da762c8
      Utkarsh Ayachit authored
      When building projects dependending on VTK, we ran into issues since some
      variables were expected to be declared e.g. VTK_WRAP_PYTHON_INIT_EXE,
      VTK_WRAP_HIERARCHY_EXE. These are unnnecessary since they are imported targets
      and should be used if present. Updated code to use the targets directly if
      found.
      
      Change-Id: I74b5996671e195b02bd65b85b71a2e33bd3ca2da
      5da762c8
  30. 04 Aug, 2012 1 commit
    • Brad King's avatar
      vtkPythonWrapping: Set python module prefix on wrapper targets · 32f9f5e7
      Brad King authored
      Commit dd2c9df0 (Cleanup building of static modules for Python,
      2012-08-02) dropped use of python_add_module but did not port all
      functionality to the new macro.  Add a missing property to remove the
      "lib" prefix from python module names.  Otherwise they cannot be
      imported by python.
      
      Change-Id: Ica3539fbb86a4147499e4bedb7dfe3900a645896
      32f9f5e7
  31. 03 Aug, 2012 2 commits
  32. 02 Aug, 2012 3 commits
    • Utkarsh Ayachit's avatar
      Fixing static python to import modules on demand. · 881e17d3
      Utkarsh Ayachit authored
      Fixing vtkPythonAppInit to import statically linked modules when first called
      rather than immediately after intialization. This was an oversight during the
      changes to cleanup static python builds.
      
      Change-Id: I2a2155c9c4d0d3109f44dafd1cf0f75b1d7f8cc6
      881e17d3
    • Utkarsh Ayachit's avatar
      Fixes bugs when BUILD_SHARED_LIBS was ON. · b1c7c43a
      Utkarsh Ayachit authored
      vtkPythonWrapping was setting dependencies even when BUILD_SHARED_LIBS was ON.
      This was resulting in vtkpython dependending on the modules are compile time
      acceidentally. Fixed that.
      
      Modules were being added using vtk_add_library() call. That call sets properties
      on the target that are not necessarily applicable to "Modules" and was raising
      compiler errors when BUILD_SHARED_LIBS was ON. Fixed that. Now vtk_add_library()
      is only called when building static (it's needed in that case since the static
      module needs to be treated as a regular library and must be added the exports so
      that applications can link against it).
      
      Change-Id: Ic0219e7b28d644e9a755fb5f494cbfc6d71dfd09
      b1c7c43a
    • Utkarsh Ayachit's avatar
      Cleanup building of static modules for Python. · dd2c9df0
      Utkarsh Ayachit authored
      This commit lays the ground work to enable building of python modules for static
      VTK builds. This cleans up the code that creates the header file with the list
      of modules to be initialized.
      
      vtkpython now can be built even when BUILD_SHARED_LIBS is OFF. It statically
      initializes the python wrapped modules.
      
      Macros to add python modules or generate initialization header file have been
      removed from FindPythonLibs.cmake (and should be deprecated from CMake as well).
      Instead new VTK-specific macros are now added to vtkPythonWrapping.cmake that
      use the information provided by the VTK-modules API to generate the
      initialization header when bulding statically.
      
      Change-Id: Icca5ccd34397f264dadfe00213501cd4a0eea8b5
      dd2c9df0
  33. 01 Aug, 2012 2 commits
    • Brad King's avatar
      Python: Restore VTK version number to python libraries · 7642e330
      Brad King authored
      The vtk_(add|module)_library macros set the OUTPUT_NAME property of the
      target to add the VTK version number to the library file name.  Since
      commit 1494cdd4 (Add python version numbers only to files, 2012-06-12)
      we set the OUTPUT_NAME property of VTK Python library targets to add the
      python version number, accidentally dropping the VTK version number.
      
      Add the python version number by getting the OUTPUT_NAME property
      value already set by vtk_add_library and replacing "Python" with
      "Python${XY}".  Then set the OUTPUT_NAME property with the result.
      
      Change-Id: Ie7ff1268162b077f7bd543df4b785dd49f1be02f
      7642e330
    • Marcus D. Hanwell's avatar
      Simplified the variable names in modular · bb7c422d
      Marcus D. Hanwell authored
      Removed the VTK_MODULE_ prefix, allowing for projects such as ParaView
      to use a common approach whether building VTK as an add_subdirectory or
      against a system installed version.
      
      Change-Id: I7733bacbf7b3f49379a709719ff63716bc56da11
      bb7c422d