1. 13 Aug, 2013 1 commit
  2. 24 Oct, 2012 1 commit
    • David Gobbi's avatar
      ENH: Make the wrappers detect abstract classes automatically. · 62700fbe
      David Gobbi authored
      Deprecate the "--abstract" and "--concrete" options for wrapper
      tools.  Also deprecate specifying an output file without "-o",
      and remove the old "infile [hintsfile] concrete outfile" calling
      convention, which hasn't been used since VTK 5.6 and was broken.
      
      The wrappers now ignore the ABSTRACT property in cmake, instead
      they automatically detect concrete classes by searching for the
      New() method.
      
      Some classes were marked as ABSTRACT, even though they had a New()
      method that returned a valid instance.  The ABSTRACT property
      has been removed from these classes, for consistency.
      
      Note that the vtkInstantiator classes still rely on the ABSTRACT
      property, so the ABSTRACT property cannot yet be removed from the
      cmake files.
      
      Change-Id: I05ebf42e69367fd4ce7256864a25d1f0c16ed4b8
      62700fbe
  3. 23 Jun, 2012 2 commits
    • David Gobbi's avatar
      ENH: Allow wrapping tools to accept argument files. · 328d974b
      David Gobbi authored
      Some compilers, including gcc and cl.exe, allow command-line
      arguments to be given in a file.  On the command line, this
      file is given as "@file" and may be intermixed with other
      command-line arguments.  This patch adds support for @file
      to the wrapper command-line tools.  The wrapper cmake macros
      have been updated to use this option, in order to reduce the
      length of the custom_command command lines for the wrapper tools.
      
      Change-Id: Id24c5f662fdcc6ca437715ca6ee01b910ab60bc1
      328d974b
    • David Gobbi's avatar
      ENH: Add static library vtkWrappingCore to share wrapper tool code. · dfcb7d1a
      David Gobbi authored
      The wrapper tools share a lot of source code, so it makes sense to
      put that code into a library.  This commit also makes a change to
      the command-line arguments for the wrapper tools: the output file
      must be specified with a "-o" option.
      
      Change-Id: I5155dd97c86ba98d91737f2691e8dfa92c28452d
      dfcb7d1a
  4. 04 Jun, 2012 1 commit
    • Marcus D. Hanwell's avatar
      Automatically set wrap exes if targets imported · 7e1c53f4
      Marcus D. Hanwell authored
      If the appropriate targets were imported, and the user did not set a
      special value for the wrapping executables then use sane defaults (those
      built by VTK).
      
      Change-Id: I32275effb918602433ca1a5bc9340d303ca9baf0
      7e1c53f4
  5. 09 May, 2012 1 commit
  6. 25 Apr, 2012 1 commit
    • David Gobbi's avatar
      COMP: Allow wrapping of headers that aren't listed in SRCS. · a98e3091
      David Gobbi authored
      In pre-modular VTK, there used to be a Kit_WRAP_HEADERS variable
      that listed config headers and other headers that did not contain
      any class definitions, but which included important constants that
      we wanted to wrap in python.
      
      When Kit_WRAP_HEADERS was removed, these headers had to be included
      in Module_SRCS in order to be wrapped by python, but then certain
      tricks were needed to exclude them from e.g. java.  This commit
      moves these headers back to HDRS, and then passes the HDRS to the
      various wrappers and allows them to decide what to do with them.
      
      Change-Id: Ieef0a7a42ab7ac0248f3635c6b460e5c08a418d4
      a98e3091
  7. 18 Apr, 2012 1 commit
    • Chris Harris's avatar
      Fix Java wrapping parallel build issue · c5cb0758
      Chris Harris authored
      Currently the VTK Java classes are compiled using generated “driver”
      classes that reference every class in a particular module. This
      "driver" class is compiled and because of the references javac
      compiles the associated classes. In a parallel build multiple
      invocation of javac are used to compile the “driver” classes, these
      interact in some way, probably a race condition to build dependencies.
      The use of the “driver” classes is unnecessary. The Java classes can
      be compiled by an invocation of javac passing in *.java, javac
      will then compile all classes and dependencies. As there is a single
      invocation there will be no parallel build issue. This also simplifies
      the CMakeLists.txt.
      
      Change-Id: I7beb8ffef0972611d5a78150e1c52e340993d740
      c5cb0758
  8. 13 Apr, 2012 1 commit
    • David Gobbi's avatar
      COMP: Trying to fix java parallel build hiccups in modular. · ddd0485b
      David Gobbi authored
      This is a follow-up to pre-modular commit 875f8232, which was a
      temporary fix to the java parallel build failure.  When the build
      fails, errors of the form "class file contains wrong class" are
      seen.  This patch reorganizes and comments the cmake code for
      clarity.  It will probably not fix the problem, but it should at
      least assist in determining the cause.
      
      This commit also puts vtkBuildAllDriver.class back in java/vtk,
      the modularization commit 0c1471f1 moved it from the java/vtk
      dir to the java dir.
      
      Change-Id: Icee402497f2d64a4dd6314a2f31e05c4e0805b91
      ddd0485b
  9. 11 Apr, 2012 1 commit
    • David Gobbi's avatar
      COMP: On OS X, vtkRenderWindowJava must have ".mm" extension. · 55e51081
      David Gobbi authored
      Because OS X Java is cocoa, and because the java wrappers add
      includes to vtkRenderWindowJava that trace back to cocoa, it
      is necessary to compile vtkRenderWindowJava with a ".mm" extension
      so that the compiler knows to compile it with Objective C++.
      
      Change-Id: I84a5741ac6193cd680dbde09e61cae4d62b88740
      55e51081
  10. 09 Apr, 2012 2 commits
    • VTK Developers's avatar
      Remove trailing whitespace from all source files · 2d323fc4
      VTK Developers authored
      Exclude ThirdParty, Utilities/MetaIO, and Utilities/KWSys as these
      are maintained outside VTK.
      
      Co-Author: Marcus D. Hanwell <marcus.hanwell@kitware.com>
      Co-Author: Chris Harris <chris.harris@kitware.com>
      Co-Author: Brad King <brad.king@kitware.com>
      2d323fc4
    • VTK Developers's avatar
      Add modular VTK build system · 0c1471f1
      VTK Developers authored
      Add module.cmake, CMakeLists.txt, and other build system files.
      
      The modular VTK build system is not yet mature.  The monolithic build
      files had a lot of infrastructure.  The modular build files reproduce
      much of the functionality but some features will need to be restored
      later.  Document status and tasks in "TODO-Modularization.txt".
      
      Co-Author: Marcus D. Hanwell <marcus.hanwell@kitware.com>
      Co-Author: Chris Harris <chris.harris@kitware.com>
      Co-Author: Brad King <brad.king@kitware.com>
      Co-Author: Nikhil Shetty <nikhil.shetty@kitware.com>
      0c1471f1
  11. 14 Oct, 2010 1 commit
  12. 16 Aug, 2010 1 commit
    • David Gobbi's avatar
      ENH: Add a preprocessor to the wrapper's parser. · 3cfbd10e
      David Gobbi authored
      The preprocessor allows robust handling of if, define, and include
      directives.  It contains its own simple parser for evaluating
      expressions using integer math.  If given include paths via "-I"
      it searches those paths, but if it does not find an include file
      then it continues without failing.  Included files are only read
      by the preprocessor, not by the main parser.
      3cfbd10e
  13. 04 Aug, 2010 1 commit
  14. 19 Jul, 2010 1 commit
    • David Gobbi's avatar
      COMP: Better way to state Java dependencies. · 5f3aba0d
      David Gobbi authored
      The dependency of vtkKitJavaJavaClasses on vtkKitJava is not a
      true dependency, but it forces the .java classes to be created
      one kit at a time, the same as the Java.cxx files.
      5f3aba0d
  15. 18 Jul, 2010 1 commit
    • David Gobbi's avatar
      COMP: Fix Java dependencies wrt Hierarchy build. · 5f66e0fb
      David Gobbi authored
      The .java files were all trying to build up-front and were causing
      the Hierarchy files to build out of order.  Making them depend on
      their kit library seems to fix the problem (it is not a true
      dependency, but it helps to make things occur in the correct
      order).  Also, the header files are now direct dependencies
      of the hierarchy file that is created from them.
      5f66e0fb
  16. 02 Jul, 2010 1 commit
  17. 04 Oct, 2006 1 commit
  18. 05 May, 2006 2 commits
  19. 04 May, 2006 1 commit
  20. 20 Jul, 2005 1 commit
  21. 06 Jan, 2005 1 commit
  22. 21 Dec, 2004 2 commits
  23. 10 Dec, 2004 1 commit
  24. 18 Nov, 2003 1 commit