From ben.boeckel at kitware.com  Wed Jan  2 14:23:53 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 2 Jan 2019 14:23:53 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
Message-ID: <20190102192353.GA24527@rotor.localdomain>

Hi all,

The new module system is in a landable state right now. We're planning
on merging it Friday (4 Jan 2019). The buildbots will be updated shortly
afterwards. Once they've been updated, `Do: test` will only work for
rebased merge requests (since the cache entries don't line up). In
addition, after the update, buildbots will default to building all
modules (turning off those which don't build).

The CMake API is now much more regular (some internal APIs have an
oddity or two we can clean up). Keyword arguments, erroring out on
unrecognized arguments, proper error messages for missing required
arguments, etc. All API functions also have a documentation block above
them in Markdown. In the future, this will be extracted and added to the
Doxygen output for VTK. In addition, no global variables[1] are used to
control the build; everything is passed in via arguments to the relevant
functions. There is one slight exception to this for APIs meant to be
called within another context. For example, `vtk_module_add_module` uses
the `LIBRARY_DESTINATION` variable passed to `vtk_module_build` for its
installation. The testing CMake APIs have a few similar expectations.

Previous discussion has occured on this thread on this list:

    https://markmail.org/thread/cu2wyqpvporqvps6

The merge request is here:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5020

ParaView's update for the new build setup will be landing in the
following days.

Changes for building VTK itself:

  - CMake 3.8 is now required. This is primarily to support
    `target_compile_features(cxx_std_11)` for having *consumers* of VTK
    also have (at least) C++11 enabled. Building with kits requires
    3.12 for object library features. Some modules require newer CMake
    versions for builtin CUDA language support (though they don't seem
    to be guarded by checks at the moment).
  - Module names have been changed. For example, `vtkCommonCore` is now
    `VTK::CommonCore`. This allows for one name to work both inside and
    outside VTK for `target_link_libraries`. Cache variable names use
    the module name.
  - Changed cache variables:
    * Module and group flags:
      - `Module_<MMM>` -> `VTK_MODULE_ENABLE_<MMM>`
      - `VTK_Group_<MMM>` -> `VTK_GROUP_ENABLE_<MMM>`
      - Values are no longer boolean, but instead 5-state:
        * `YES`: Must be built
        * `NO`: Must not be built (turns off modules requiring it;
          errors if required by a `YES` module)
        * `WANT`: Build if possible
        * `DONT_WANT`: Build only if necessary
        * `DEFAULT`: Use group (for modules) and `VTK_BUILD_ALL_MODULES`
          instead
      - `VTK_USE_SYSTEM_<MMM>` -> `VTK_MODULE_USE_EXTERNAL_<MMM>`
        Third party modules which don't support an external version no
        longer have an option available.
  - Turning off Python forces Python modules off.
  - Turning off Java forces Java modules off.
  - Turning off MPI forces MPI modules off.
  - Configuring VTK is now faster. An "all modules" build with Python
    wrapping enabled:

      cmake .  4.68s user 0.84s system 98% cpu 5.578 total

    Doing this on `master` on the same machine and Python *off*:

      cmake .  25.44s user 19.79s system 99% cpu 45.297 total

    This is not a scientific comparison; the module set is as close as I
    could make it, but if anything, `master` has fewer modules enabled
    (find modules not working, Python being disabled, some modules are
    new due to splitting, etc.).
  - CMake output is now minimal. Here is the complete output from
    reconfiguring VTK:

    % cmake .
    -- HDF5: Using hdf5 compiler wrapper to determine C configuration
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/boeckb/code/depot/group-kitware/vtk/build

    Not sure where the HDF5 output is coming from; might be a bug in
    `FindHDF5`.
  - The VTKm submodule has moved one directory lower (it is now
    ThirdParty/vtkm/vtkvtkm/vtk-m so that the settings for a local VTKm
    are localized).

For development:

  - Adding a module is similar to before. See `vtk.module` files in the
    source tree.
  - All files should be included in the source listing for modules.
    Using `CLASSES` is the same as doing `<NAME>.cxx` as a source and
    `<NAME>.h` as a public header. Private headers should use
    `PRIVATE_HEADERS` (e.g., object factory files).
  - To hide a module from a build (e.g., a Windows-only module), the
    `CONDITION` argument should be used in the `vtk.module` file. This
    is done for the Python and Java modules.
  - The object factory API has also been updated to the same patterns as
    the new module system (output variables rather than directory
    properties). See existing code for usage.
  - The new CMake API only works when controlled via the
    `vtk_module_scan` and `vtk_module_build` functions. Global and
    target properties are used to store information, so
    `vtk_module_add_module` doesn't work with just a simple
    `add_subdirectory`).
  - Due to kits being a thing, the backing target for a module may have
    different names based of CMake flags. Basically, CMake's `target_`
    commands need to be given `CommonCore`, `VTK::CommonCore`, or
    `CommonCore-objects` based on the build settings. To simplify this,
    there are functions like `vtk_module_include` or `vtk_module_link`
    for handling modules. Similarly for properties, there is
    `vtk_module_set_property`.
  - Prefer imported targets rather than `INCLUDE_DIRS` and `LIBRARIES`
    variables. This ensures that usage requirements are properly done
    and that VTK is relocatable once installed.
  - Public cache variables should be placed as close to their usage as
    possible. For example, the OpenGL settings are now in
    `Utilities/OpenGL` rather than the top level.

For consumers of VTK:

  - `find_package(VTK COMPONENTS CommonCore)` should be used.
    `OPTIONAL_COMPONENTS` is also supported.
  - Install tree is largely the same layout (library names are still
    `vtkCommonCore-X.Y`).
  - For object factories to work, `vtk_module_autoinit` should be used.
    This generates the proper `-D` flags for getting initialization to
    work.
  - Language wrapping APIs is now *much* simpler. Here is the call to
    wrap VTK's modules in Python:

      vtk_module_wrap_python(
        MODULES         ${vtk_modules}
        INSTALL_EXPORT  VTK
        PYTHON_PACKAGE  "vtkmodules"
        MODULE_DESTINATION  "${VTK_PYTHON_SITE_PACKAGES_SUFFIX}"
        CMAKE_DESTINATION   "${vtk_cmake_destination}"
        WRAPPED_MODULES vtk_python_wrapped_modules
        TARGET          VTK::vtkpythonmodules)

    and Java:

      vtk_module_wrap_java(
        JAVA_OUTPUT     "${CMAKE_CURRENT_BINARY_DIR}/src/vtk"
        MODULES         ${vtk_modules}
        WRAPPED_MODULES vtk_java_wrapped_modules)

  - No more PythonD libraries. VTK modules now import their dependent
    modules automatically rather than linking to the backing
    implementations directly (mainly a packager detail, but important).

Things I've noticed on this adventure:

  - To default a module to being built, add it to a group that is on by
    default (currently just `StandAlone` and `Rendering`). Excess
    dependencies is not the way to do this.
  - There are a few modules with debug code which uses modules not in
    the dependency list. Debug code should constrain itself to the same
    dependencies the rest of the code uses (or have just a comment in
    the `vtk.module` file as to its use).

Current state:

  - Fewer than 25 (out of 2000+) tests failing on a build everything[2]
    build with Python enabled.
  - Python optional linking is currently disabled. On Linux, linking
    errors cropped up and macOS had runtime errors appear. Investigation
    is needed.
  - Some examples disabled (Medical and Modelling are ported, but
    *their* tests fail right now). Those with `UNMAINTAINED.md` files
    are *not* ported.
  - The Medical and Modelling examples are disabled. They run tests
    during which fail. Investigation is nedded.
  - Debug points need to be added. However, I'd like to see where
    they're commonly necessary before adding them everywhere they
    *might* be useful. Places I can forsee it being nice to have:
    * Why is this test module not enabled?
    * Why is this module built?
    * Why is this module not built?
  - Remote modules have not been ported nor are the download/build
    mechanisms wired up.
  - There seems to be some issue with finding GLX on some Ubuntu
    installs with custom nvidia driver installations. It's likely
    something wrong with FindOpenGL, but more information needs to be
    gathered.

Near future tasks:

  - The new module system now supports optional test dependencies.
    Moving some test dependencies to be optional and only building the
    parts of the test suite that can would help improve how much of the
    test suite runs in smaller builds.
  - Excess data. There is data that nothing uses (input and baselines).
    This should be sorted through and we should figure out whether they
    were missed when removing old tests or new tests should be written
    to use the data.
  - Updating WikiExamples to use the new system.

Further future tasks:

  - Update Python code to `from vtkmodules.MMM import XXX` instead of
    `from vtk import XXX`. This should vastly improve Python test times.
  - Reducing the number of `try_compile` performed. This will immensely
    help with initial configure times. One idea is to port third party
    libraries over to using KWIML for builtin types rather than checking
    their sizes and signedness at configure time. Upstreamable solutions
    are preferred however.

Third party packages in VTK have also been updated. In general, they no
longer add (visible) cache entries at all and their `try_compile` tests
have been minimized. Here's the current listing of internal third party
libraries in VTK:

  diy2-3.5.0 (I)            libproj 4.9.3       tiff 4.0.6
  doubleconversion 3.1.1    libxml2 2.9.8       utf8 2.3.4 (I)
  eigen 3.3.5               lz4 1.8.3           verdict 1.2.0 (IC)
  exodusII 7.15f (I)        lzma 5.2.4          vpic ???
  expat 2.2.6               mpi4py 2.0.0        vtk-m <master> (I)
  freetype 2.9.1            netcdf 4.6.1        xdmf2 1.2.11 (I)
  gl2ps 1.4.0 (P)           ogg 1.3.3           xdmf3 1.2.11 (I)
  glew 2.1.0                pegtl 2.7.1 (I)     zfp 0.5.4 (I)
  hdf5 1.10.3               png 1.6.35          zlib 1.2.11
  jpeg 2.0.0                pugixml 1.9         kwiml <master> (I)
  jsoncpp 1.8.4             sqlite 3.25.2       kwsys <master> (I)
  kissfft ??? (I)           theora 1.1.1        metaio <master> (I)
  libharu 2.4.0 (P)

  - `C` means it needs converted to use `update.sh` yet
  - `I` means external versions are not supported
  - `P` means upstream needs to merge some PRs before an external
    version would actually work (links to PRs in the relevant CMake
    file)

CDash will now be showing all warnings again (I cleaned out the regular
expressions since third party libraries have been uplifted). I've also
pushed many GCC 8 warning fixes upstream, so MSVC should be the only one
with oodles of warnings yet. When adding exclusions back, please include
comments as to why they are there and, if applicable, a link to an issue
about actually addressing them.

--Ben

[1]There are a few global variables that are read, but they only control
*defaults* to cache variables, not the variable itself (e.g., defaulting
StandAlone and Rendering groups to be built).

[2]Some modules were excluded from this testing on some platforms due to
a lack of dependencies on the testing machines:

Linux:
    VTK::FiltersOpenTurns     VTK::RenderingOculus
    VTK::IOADIOS              VTK::RenderingOpenVR
    VTK::IOPDAL               VTK::RenderingOptiX
    VTK::RenderingOSPRay
macOS:
    VTK::FiltersOpenTurns     VTK::RenderingOSPRay
    VTK::IOADIOS              VTK::RenderingOculus
    VTK::IOMySQL              VTK::RenderingOpenVR
    VTK::IOPDAL               VTK::RenderingOptiX
    VTK::IOPostgreSQL         VTK::mpi
    VTK::Java
Windows:
    VTK::DomainsMicroscopy    VTK::IOPostgreSQL
    VTK::FiltersOpenTurns     VTK::InfovisBoost
    VTK::FiltersReebGraph     VTK::InfovisBoostGraphAlgorithms
    VTK::GUISupportMFC        VTK::Java
    VTK::IOADIOS              VTK::RenderingExternal
    VTK::IOFFMPEG             VTK::RenderingFreeTypeFontConfig
    VTK::IOGDAL               VTK::RenderingOSPRay
    VTK::IOIODBC              VTK::RenderingOculus
    VTK::IOLAS                VTK::RenderingOpenVR
    VTK::IOPDAL               VTK::RenderingOptiX
    VTK::IOPDAL               VTK::xdmf3

Code itself was not touched except where errors were otherwise found.

From dave.demarle at kitware.com  Wed Jan  2 16:13:23 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 2 Jan 2019 16:13:23 -0500
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
Message-ID: <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>

I've been holding off 8.2.0.final to get a better handle on wheel building.

Please review the potential fix in:
https://gitlab.kitware.com/vtk/vtk/merge_requests/5021

@Prabhu Ramachandran <prabhu at aero.iitb.ac.in>, @Jean-Christophe
Fillion-Robin <jcfr at kitware.com> building the wheels seem to be OK off of
this on my desktop. How do I locally test their validity?

David E DeMarle
Kitware, Inc.
Principal Engineer


On Thu, Dec 6, 2018 at 11:48 AM David E DeMarle <dave.demarle at kitware.com>
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?
>
> https://gitlab.kitware.com/demarle/vtk/commits/WIP-break-wrappings-vtkpythoninterpreter-dependency
> 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 <
> vtk-developers at public.kitware.com> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190102/837da11e/attachment.html>

From matt.mccormick at kitware.com  Wed Jan  2 16:30:50 2019
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 2 Jan 2019 16:30:50 -0500
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
 <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
Message-ID: <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>

On Wed, Jan 2, 2019 at 4:13 PM David E DeMarle via vtk-developers
<vtk-developers at vtk.org> wrote:
>
> I've been holding off 8.2.0.final to get a better handle on wheel building.
>
> Please review the potential fix in: https://gitlab.kitware.com/vtk/vtk/merge_requests/5021

Excellent, thanks!

This looks good to me.


> @Prabhu Ramachandran, @Jean-Christophe Fillion-Robin building the wheels seem to be OK off of this on my desktop. How do I locally test their validity?

Create a virtualenv, make sure pip can recognize and install the wheel
from the local directory, and test it on VTK examples. For example,

  python3 -m venv test-venv
  ./test-venv/bin/python -m pip install --upgrade pip
  ./test-venv/bin/python -m pip install numpy
  # dist/ contains the generated vtk-8.2.0-cp36-cp36m-manylinux1_x86_64.whl
  ./test-venv/bin/python -m pip install vtk --no-cache-dir --no-index -f ./dist/
  ./test-venv/bin/python /path/to/vtk/script.py


HTH,
Matt

From prabhu at aero.iitb.ac.in  Wed Jan  2 22:17:18 2019
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Thu, 3 Jan 2019 08:47:18 +0530
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
 <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
 <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>
Message-ID: <6c547744-6d6c-fcf3-d599-3b6b157509e9@aero.iitb.ac.in>

Sorry I dropped off the radar.? I have been traveling and my semester starts
today.? I can try this weekend and test it out.? Does that work?

Regards,
Prabhu

On 1/3/19 3:00 AM, Matt McCormick wrote:
> On Wed, Jan 2, 2019 at 4:13 PM David E DeMarle via vtk-developers
> <vtk-developers at vtk.org> wrote:
>> I've been holding off 8.2.0.final to get a better handle on wheel building.
>>
>> Please review the potential fix in: https://gitlab.kitware.com/vtk/vtk/merge_requests/5021
> Excellent, thanks!
>
> This looks good to me.
>
>
>> @Prabhu Ramachandran, @Jean-Christophe Fillion-Robin building the wheels seem to be OK off of this on my desktop. How do I locally test their validity?
> Create a virtualenv, make sure pip can recognize and install the wheel
> from the local directory, and test it on VTK examples. For example,
>
>   python3 -m venv test-venv
>   ./test-venv/bin/python -m pip install --upgrade pip
>   ./test-venv/bin/python -m pip install numpy
>   # dist/ contains the generated vtk-8.2.0-cp36-cp36m-manylinux1_x86_64.whl
>   ./test-venv/bin/python -m pip install vtk --no-cache-dir --no-index -f ./dist/
>   ./test-venv/bin/python /path/to/vtk/script.py
>
>
> HTH,
> Matt
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190103/eb65bea8/attachment.html>

From dave.demarle at kitware.com  Thu Jan  3 11:25:33 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 3 Jan 2019 11:25:33 -0500
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <6c547744-6d6c-fcf3-d599-3b6b157509e9@aero.iitb.ac.in>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
 <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
 <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>
 <6c547744-6d6c-fcf3-d599-3b6b157509e9@aero.iitb.ac.in>
Message-ID: <CANjZAi9-FKaPTdU+7sbgaWzUr38Y-8xjYHKACTP0rZFRDUNByw@mail.gmail.com>

Yes please do give it a try. Note : I am running into other issues making
the wheels for 8.2.0. If I could get you and/or JC to take a look it would
be great.

My WIP branch: https://github.com/demarle/VTKPythonPackage/tree/bump-to-8.2
Results in:
running clean
removing '_skbuild/linux-x86_64-3.6/cmake-install'
removing '_skbuild/linux-x86_64-3.6/cmake-build'
removing '_skbuild/linux-x86_64-3.6'
+ find /work/VTK-cp36-cp36m-manylinux1_x64 -name '*.o' -delete
++ uname -p
+ for whl in 'dist/*linux_$(uname -p).whl'
+ auditwheel repair dist/vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
--lib-sdir . -w /work/dist/
Repairing vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
Traceback (most recent call last):
  File "/usr/local/bin/auditwheel", line 11, in <module>
    sys.exit(main())
  File
"/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main.py",
line 49, in main
    rval = args.func(args, p)
  File
"/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main_repair.py",
line 77, in execute
    update_tags=args.UPDATE_TAGS)
  File
"/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/repair.py",
line 82, in repair_wheel
    soname)
ValueError: Cannot repair wheel, because required library
"libvtkImaging-8.2.so.1" could not be located

Where the specific library changes each run. On the same machine, running
master  of VTKPyPackage (so vtk 8.1.2) works fine.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Wed, Jan 2, 2019 at 10:17 PM Prabhu Ramachandran <prabhu at aero.iitb.ac.in>
wrote:

> Sorry I dropped off the radar.  I have been traveling and my semester
> starts today.  I can try this weekend and test it out.  Does that work?
>
> Regards,
> Prabhu
>
> On 1/3/19 3:00 AM, Matt McCormick wrote:
>
> On Wed, Jan 2, 2019 at 4:13 PM David E DeMarle via vtk-developers<vtk-developers at vtk.org> <vtk-developers at vtk.org> wrote:
>
> I've been holding off 8.2.0.final to get a better handle on wheel building.
>
> Please review the potential fix in: https://gitlab.kitware.com/vtk/vtk/merge_requests/5021
>
> Excellent, thanks!
>
> This looks good to me.
>
>
>
> @Prabhu Ramachandran, @Jean-Christophe Fillion-Robin building the wheels seem to be OK off of this on my desktop. How do I locally test their validity?
>
> Create a virtualenv, make sure pip can recognize and install the wheel
> from the local directory, and test it on VTK examples. For example,
>
>   python3 -m venv test-venv
>   ./test-venv/bin/python -m pip install --upgrade pip
>   ./test-venv/bin/python -m pip install numpy
>   # dist/ contains the generated vtk-8.2.0-cp36-cp36m-manylinux1_x86_64.whl
>   ./test-venv/bin/python -m pip install vtk --no-cache-dir --no-index -f ./dist/
>   ./test-venv/bin/python /path/to/vtk/script.py
>
>
> HTH,
> Matt
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190103/61af9b8e/attachment.html>

From ben.boeckel at kitware.com  Thu Jan  3 15:16:22 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 3 Jan 2019 15:16:22 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190102192353.GA24527@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
Message-ID: <20190103201622.GA11008@rotor.localdomain>

On Wed, Jan 02, 2019 at 14:23:53 -0500, Ben Boeckel wrote:
> The new module system is in a landable state right now. We're planning
> on merging it Friday (4 Jan 2019).

This has been delayed until at least Monday afternoon.

> The buildbots will be updated shortly afterwards.

The change is pending for this. Buildbots will now build "all" modules
by default and we'll turn off those that don't build on the machines.
This means that new modules in merge requests will be tested by default
as well. Some post-merge work to clean up the set of test exclusions and
disabling modules will be necessary.

--Ben

From bill.lorensen at gmail.com  Thu Jan  3 18:23:18 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 3 Jan 2019 15:23:18 -0800
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190103201622.GA11008@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190103201622.GA11008@rotor.localdomain>
Message-ID: <CADZJ4hPQGhR4LvpVvPMy5Mrc+FvnVqCYwA3u_q5ocjCPxkcHkA@mail.gmail.com>

I'm not sure if I asked this before? Can the old and new module system
coexist?

On Thu, Jan 3, 2019, 12:16 PM Ben Boeckel via vtk-developers <
vtk-developers at vtk.org wrote:

> On Wed, Jan 02, 2019 at 14:23:53 -0500, Ben Boeckel wrote:
> > The new module system is in a landable state right now. We're planning
> > on merging it Friday (4 Jan 2019).
>
> This has been delayed until at least Monday afternoon.
>
> > The buildbots will be updated shortly afterwards.
>
> The change is pending for this. Buildbots will now build "all" modules
> by default and we'll turn off those that don't build on the machines.
> This means that new modules in merge requests will be tested by default
> as well. Some post-merge work to clean up the set of test exclusions and
> disabling modules will be necessary.
>
> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190103/c1a994d5/attachment.html>

From ben.boeckel at kitware.com  Fri Jan  4 09:10:46 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 4 Jan 2019 09:10:46 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <CADZJ4hPQGhR4LvpVvPMy5Mrc+FvnVqCYwA3u_q5ocjCPxkcHkA@mail.gmail.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190103201622.GA11008@rotor.localdomain>
 <CADZJ4hPQGhR4LvpVvPMy5Mrc+FvnVqCYwA3u_q5ocjCPxkcHkA@mail.gmail.com>
Message-ID: <20190104141046.GA5462@rotor.localdomain>

On Thu, Jan 03, 2019 at 15:23:18 -0800, Bill Lorensen wrote:
> I'm not sure if I asked this before? Can the old and new module system
> coexist?

>From VTK's side, not really (i.e., it can't provide both at the same
time). There are just core incompatibilities between the two (the
current one is allergic to imported targets and the new one strongly
prefers them).

For projects providing VTK modules, it won't be easy, but should be
possible.

For projects just consuming VTK, supporting VTK 8.2 and 9.0 at the same
time is possible with a few if blocks and variables for abstraction. I
plan on getting to WikiExamples after ParaView has its merge.

--Ben

From lucas.gandel at kitware.com  Mon Jan  7 04:38:32 2019
From: lucas.gandel at kitware.com (Lucas Gandel)
Date: Mon, 7 Jan 2019 10:38:32 +0100
Subject: [vtk-developers] vtk-glTF
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30EA1D0664@ex14mb4.win.rpi.edu>
References: <YQXPR0101MB123844A2C6AA2287F564A24395D30@YQXPR0101MB1238.CANPRD01.PROD.OUTLOOK.COM>
 <CANXz0SYqROeQ75x4HJ4c7aNfksmG+Mvjx4sKhU9NeinxUw6CBQ@mail.gmail.com>
 <CADkb7uOsVeUo0=GoBxWoJGva_EeymYA7Dc6=NNtR=-HNKTpCUg@mail.gmail.com>
 <CAEw35Z_cLdkDuYCuKP5U5AhEAz_t0HgU7RuX+Y0x--q0PyyG7w@mail.gmail.com>
 <CAC2t4USs9hqm8_o3-Jqdkn2NjU+y0faWWndnrqZs-GTS7JLf-A@mail.gmail.com>
 <CAEw35Z_3WkE0JZnvx9jOC0mnY7H_N45r3HpXtVvkadZmFRHA9Q@mail.gmail.com>
 <CAG1Y6mD_zz2-NqpYjCb2=r1Pq60-hZM52eu-2HWsjOAGPmNHiA@mail.gmail.com>
 <CANXz0Sake1ucTUw2_PwtGPAFEK9jmd1vkSRgq75LdrP0HLHfMQ@mail.gmail.com>
 <CALzTN-Syezg5z74LdseOLCk2M_jozfHJEm9PwjaEFDdOFyiKwQ@mail.gmail.com>
 <CABObKxejf9iCJbzk9QZuCw+GmSNATC5HrUOgd8VmdekxpwTzMw@mail.gmail.com>
 <CAG1Y6mBARAQYJ9Z9f4-T+8XNgACb1JUYCjtFU11quDpg8HSKMw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30EA1D0664@ex14mb4.win.rpi.edu>
Message-ID: <CAEGO0EoMgNWDF_A0=+5szBbyOLFG1ahX9a0T1StAdAdSpBy2yg@mail.gmail.com>

Following up on this, I've been trying to integrate Assimp into VTK to
perform skinning/skeletal animation.
First results look very promising. I'll try to share a branch within the
next few weeks when it is ready.


On Fri, Nov 30, 2018 at 7:31 PM Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> I also integrated Assimp with a fork of VTK before as well, but it was for
> something very specific because we needed bone weights/indices. However,
> from what I understand, Assimp seems to internally process the mesh data,
> so you may get slightly different results than the vtkOBJReader (for
> instance) because of vertex reordering.
>
> ------------------------------
> *From:* Alexis Girault [alexis.girault at kitware.com]
> *Sent:* Friday, November 30, 2018 12:37 PM
> *To:* Milef, Nicholas Boris; Aashish Chaudhary; Mathieu Westphal
> *Cc:* Ken Martin; Steve Pieper; vtk-developers at public.kitware.com
> *Subject:* Re: [vtk-developers] vtk-glTF
>
> Nicholas Milef from RPI was the one who inquired about ASSIMP in VTK:
> http://vtk.1045678.n5.nabble.com/Assimp-integration-td5741474.html
> CCing in case he wants to follow up on it
>
> Nick also integrated ASSIMP in iMSTK. To answer your question Aashish:
> - iMSTK has its own data structure for geometries that uses Eigen:
> https://gitlab.kitware.com/iMSTK/iMSTK/tree/master/Source/Geometry/Mesh
> - The ASSIMP importer converts (copies) the data from ASSIMP to those
> internal Eigen structures:
> https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Source/Geometry/Reader/imstkAssimpMeshIO.cpp
> - The geometry vertices are mapped to a VTK data array with no copy:
> https://gitlab.kitware.com/iMSTK/iMSTK/blob/85c154f1/Source/Rendering/VTKRenderer/RenderDelegate/imstkVTKSurfaceMeshRenderDelegate.cpp#L48-52
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x325
>
>
> On Fri, Nov 30, 2018 at 10:50 AM Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> I would love that, but I'm not aware of any.
>>
>> On Fri, Nov 30, 2018 at 8:46 AM Matt McCormick <
>> matt.mccormick at kitware.com> wrote:
>>
>>> Are there any plans for a glTF reader in vtk.js? With a writer in VTK,
>>> this may be an efficient path for VTK/ITK output in WebAssembly rendered in
>>> vtk.js.
>>>
>>> - Matt
>>>
>>> On Fri, Nov 30, 2018 at 10:23 AM Ken Martin via vtk-developers <
>>> vtk-developers at public.kitware.com> wrote:
>>>
>>>> Has anyone looked into putting assimp into VTK?
>>>>
>>>> On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers <
>>>> vtk-developers at public.kitware.com> wrote:
>>>>
>>>>> For a list of existing IO toolkits, see "Converters, Importers, and
>>>>> Exporters"  on Khronos page for gltf here:
>>>>> https://www.khronos.org/gltf/
>>>>>
>>>>> In iMSTK, we have been using ASSIMP <http://www.assimp.org/> (mentioned
>>>>> in the list above) for some other formats. I believe people inquired about
>>>>> integrating ASSIMP in VTK in the past.
>>>>>
>>>>> Alexis Girault
>>>>> R&D Engineer in Medical Computing
>>>>> Kitware, Inc.
>>>>>
>>>>> http://www.kitware.com
>>>>> (919) 969-6990 x325
>>>>>
>>>>>
>>>>> On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers <
>>>>> vtk-developers at public.kitware.com> wrote:
>>>>>
>>>>>> Yes please do. You could post the updates on the mailing list (dev).
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal <
>>>>>> mathieu.westphal at kitware.com> wrote:
>>>>>>
>>>>>>> HI Aashish, list,
>>>>>>>
>>>>>>> We are currently working on a gltf reader ! But only for next year.
>>>>>>> Let us know if you want to be kept in the loop.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Mathieu Westphal
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers
>>>>>>> <vtk-developers at public.kitware.com> wrote:
>>>>>>>
>>>>>>>> Having a glTF reader/writer would be great to have in VTK
>>>>>>>> specifically for us as geospatial community is producing more data in this
>>>>>>>> format.
>>>>>>>>
>>>>>>>> - Aashish
>>>>>>>>
>>>>>>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper <pieper at isomics.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi -
>>>>>>>>>
>>>>>>>>> I'd love to see a glTF 2.0 exporter native in VTK.  I wrote a glTF
>>>>>>>>> 1.0 version in python a while back if you want to look at that for
>>>>>>>>> reference [1].
>>>>>>>>>
>>>>>>>>> On request: please include a WriteToMemory option like in the
>>>>>>>>> vtkImageWriter classes so it can be used easily without the file system
>>>>>>>>> (e.g. like in the web server mode I was doing).
>>>>>>>>>
>>>>>>>>> Good luck,
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457
>>>>>>>>>
>>>>>>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers <
>>>>>>>>> vtk-developers at public.kitware.com> wrote:
>>>>>>>>>
>>>>>>>>>> FWIW I'm working on a simple very basic starting point for gltf
>>>>>>>>>> ala
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a
>>>>>>>>>>
>>>>>>>>>> if you want to work off that. I'll probably try merging it soon .
>>>>>>>>>>
>>>>>>>>>> - Ken
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib <
>>>>>>>>>> sal.choueib at queensu.ca> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello All,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    We are currently in the process of developing an exporter to
>>>>>>>>>>> glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows
>>>>>>>>>>> of any resources that might be useful?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    Furthermore, we are utilizing tiny-gltf, a header only glTF
>>>>>>>>>>> library, to serialize data and write the gltf file (
>>>>>>>>>>> https://github.com/syoyo/tinygltf
>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsyoyo%2Ftinygltf&data=02%7C01%7C%7Cb483f966d3e64e639c5f08d653be573f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636788474294213389&sdata=W7iwlPE31LC0XVeJoEos9iVdcZCWmR%2BCwZe%2Bp%2FIP4EE%3D&reserved=0>).
>>>>>>>>>>> We are hoping someone could comment on our choice of library. Is this
>>>>>>>>>>> library good? Any potential risks or cons to using this library? Does
>>>>>>>>>>> anyone have suggestions for a better library to use?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   Thank you for your help,
>>>>>>>>>>>
>>>>>>>>>>> Sal
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ken Martin PhD
>>>>>>>>>> Distinguished Engineer
>>>>>>>>>> Kitware Inc.
>>>>>>>>>> 101 East Weaver Street
>>>>>>>>>> <https://maps.google.com/?q=101+East+Weaver+Street+Carrboro,+North+Carolina+%0D%0A27510+USA&entry=gmail&source=g>
>>>>>>>>>> Carrboro, North Carolina
>>>>>>>>>> <https://maps.google.com/?q=101+East+Weaver+Street+Carrboro,+North+Carolina+%0D%0A27510+USA&entry=gmail&source=g>
>>>>>>>>>> 27510 USA
>>>>>>>>>> <https://maps.google.com/?q=101+East+Weaver+Street+Carrboro,+North+Carolina+%0D%0A27510+USA&entry=gmail&source=g>
>>>>>>>>>>
>>>>>>>>>> This communication, including all attachments, contains
>>>>>>>>>> confidential and legally privileged information, and it is intended only
>>>>>>>>>> for the use of the addressee.  Access to this email by anyone else is
>>>>>>>>>> unauthorized. If you are not the intended recipient, any disclosure,
>>>>>>>>>> copying, distribution or any action taken in reliance on it is prohibited
>>>>>>>>>> and may be unlawful. If you received this communication in error please
>>>>>>>>>> notify us immediately and destroy the original message.  Thank you.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *| Aashish Chaudhary | Technical Leader          | Kitware Inc.
>>>>>>>>         *
>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html
>>>>>>>> <http://www.kitware.com/company/team/chaudhary.html>*
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ken Martin PhD
>>>> Distinguished Engineer
>>>> Kitware Inc.
>>>> 101 East Weaver Street
>>>> Carrboro, North Carolina
>>>> 27510 USA
>>>>
>>>> This communication, including all attachments, contains confidential
>>>> and legally privileged information, and it is intended only for the use of
>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>> you received this communication in error please notify us immediately and
>>>> destroy the original message.  Thank you.
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190107/78ba1785/attachment-0001.html>

From ken.martin at kitware.com  Mon Jan  7 11:39:17 2019
From: ken.martin at kitware.com (Ken Martin)
Date: Mon, 7 Jan 2019 11:39:17 -0500
Subject: [vtk-developers] DebugLeaks C++ expert issue?
Message-ID: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>

On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is
complaining about vtkCommands being leaked because the two string literals
in the below code have different addresses (the string address is used in a
map type structure). Looking at DebugLeaks the only way this code would
work is if they have the same address. But I checked in the debugger and
they have different addresses.


//----------------------------------------------------------------
vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
{
#ifdef VTK_DEBUG_LEAKS
vtkDebugLeaks::ConstructClass("vtkCommand or subclass");
#endif
}

//----------------------------------------------------------------
void vtkCommand::UnRegister()
{
int refcount = this->GetReferenceCount()-1;
this->SetReferenceCount(refcount);
if (refcount <= 0)
{
#ifdef VTK_DEBUG_LEAKS
vtkDebugLeaks::DestructClass("vtkCommand or subclass");
#endif
delete this;
}
}

I can fix it by doing the following but wanted a c++ expert to weigh in,
was the original code OK? Is this a compiler compliance issue? Is the
proposed fix the right approach?

const char *cname = "vtkCommand or subclass";

//----------------------------------------------------------------
vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
{
#ifdef VTK_DEBUG_LEAKS
vtkDebugLeaks::ConstructClass(cname);
#endif
}

//----------------------------------------------------------------
void vtkCommand::UnRegister()
{
int refcount = this->GetReferenceCount()-1;
this->SetReferenceCount(refcount);
if (refcount <= 0)
{
#ifdef VTK_DEBUG_LEAKS
vtkDebugLeaks::DestructClass(cname);
#endif
delete this;
}
}


Thanks!
Ken


-- 
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190107/807f137a/attachment.html>

From ben.boeckel at kitware.com  Mon Jan  7 11:59:07 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 7 Jan 2019 11:59:07 -0500
Subject: [vtk-developers] DebugLeaks C++ expert issue?
In-Reply-To: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
References: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
Message-ID: <20190107165907.GA2027@megas.kitware.com>

On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:
> On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is
> complaining about vtkCommands being leaked because the two string literals
> in the below code have different addresses (the string address is used in a
> map type structure). Looking at DebugLeaks the only way this code would
> work is if they have the same address. But I checked in the debugger and
> they have different addresses.
> 
> <snip>
> 
> I can fix it by doing the following but wanted a c++ expert to weigh in,
> was the original code OK? Is this a compiler compliance issue? Is the
> proposed fix the right approach?

I don't think the standard says anything about a string literal with the
same content as another literal having to share an address. I'd expect
that this is mainly optimization at the compiler or linker level. For
example, this:

    const char* foo = "foobar";
    const char* bar = "bar";

can be satisfied with this in the resulting binary:

    "foobar\0"
     ^  ^
     |  bar
     foo

but I'd expect the standard to say that doing `foo < bar` is always
undefined behavior since they're not pointers to the same object.

> const char *cname = "vtkCommand or subclass";
> 
> //----------------------------------------------------------------
> vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
> {
> #ifdef VTK_DEBUG_LEAKS
> vtkDebugLeaks::ConstructClass(cname);
> #endif
> }
> 
> //----------------------------------------------------------------
> void vtkCommand::UnRegister()
> {
> int refcount = this->GetReferenceCount()-1;
> this->SetReferenceCount(refcount);
> if (refcount <= 0)
> {
> #ifdef VTK_DEBUG_LEAKS
> vtkDebugLeaks::DestructClass(cname);
> #endif
> delete this;
> }
> }

This looks reasonable to me. Maybe add `static`?

--Ben

From DLRdave at aol.com  Mon Jan  7 14:40:40 2019
From: DLRdave at aol.com (David Cole)
Date: Mon, 7 Jan 2019 14:40:40 -0500
Subject: [vtk-developers] DebugLeaks C++ expert issue?
In-Reply-To: <20190107165907.GA2027@megas.kitware.com>
References: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
 <20190107165907.GA2027@megas.kitware.com>
Message-ID: <CAKME8fH1YagDssVcrQN-_tN-DLMja7_6h96oTUV1ynG0ehuDCQ@mail.gmail.com>

Is it built with the /GF compiler flag?

https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017


On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers
<vtk-developers at vtk.org> wrote:
>
> On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:
> > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is
> > complaining about vtkCommands being leaked because the two string literals
> > in the below code have different addresses (the string address is used in a
> > map type structure). Looking at DebugLeaks the only way this code would
> > work is if they have the same address. But I checked in the debugger and
> > they have different addresses.
> >
> > <snip>
> >
> > I can fix it by doing the following but wanted a c++ expert to weigh in,
> > was the original code OK? Is this a compiler compliance issue? Is the
> > proposed fix the right approach?
>
> I don't think the standard says anything about a string literal with the
> same content as another literal having to share an address. I'd expect
> that this is mainly optimization at the compiler or linker level. For
> example, this:
>
>     const char* foo = "foobar";
>     const char* bar = "bar";
>
> can be satisfied with this in the resulting binary:
>
>     "foobar\0"
>      ^  ^
>      |  bar
>      foo
>
> but I'd expect the standard to say that doing `foo < bar` is always
> undefined behavior since they're not pointers to the same object.
>
> > const char *cname = "vtkCommand or subclass";
> >
> > //----------------------------------------------------------------
> > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
> > {
> > #ifdef VTK_DEBUG_LEAKS
> > vtkDebugLeaks::ConstructClass(cname);
> > #endif
> > }
> >
> > //----------------------------------------------------------------
> > void vtkCommand::UnRegister()
> > {
> > int refcount = this->GetReferenceCount()-1;
> > this->SetReferenceCount(refcount);
> > if (refcount <= 0)
> > {
> > #ifdef VTK_DEBUG_LEAKS
> > vtkDebugLeaks::DestructClass(cname);
> > #endif
> > delete this;
> > }
> > }
>
> This looks reasonable to me. Maybe add `static`?
>
> --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://vtk.org/mailman/listinfo/vtk-developers
>

From elvis.stansvik at orexplore.com  Mon Jan  7 15:51:44 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Mon, 7 Jan 2019 21:51:44 +0100
Subject: [vtk-developers] DebugLeaks C++ expert issue?
In-Reply-To: <CAKME8fH1YagDssVcrQN-_tN-DLMja7_6h96oTUV1ynG0ehuDCQ@mail.gmail.com>
References: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
 <20190107165907.GA2027@megas.kitware.com>
 <CAKME8fH1YagDssVcrQN-_tN-DLMja7_6h96oTUV1ynG0ehuDCQ@mail.gmail.com>
Message-ID: <CAE-7VJmkh577a3BN6us0be1wibi4cawvgi-FBof_9KZGJOq_Lw@mail.gmail.com>

Den m?n 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers
<vtk-developers at vtk.org>:
>
> Is it built with the /GF compiler flag?
>
> https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017

(Also note that flag is in effect when /O1 or /O2 is used)

>
>
> On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers
> <vtk-developers at vtk.org> wrote:
> >
> > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:
> > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is
> > > complaining about vtkCommands being leaked because the two string literals
> > > in the below code have different addresses (the string address is used in a
> > > map type structure). Looking at DebugLeaks the only way this code would
> > > work is if they have the same address. But I checked in the debugger and
> > > they have different addresses.
> > >
> > > <snip>
> > >
> > > I can fix it by doing the following but wanted a c++ expert to weigh in,
> > > was the original code OK? Is this a compiler compliance issue? Is the
> > > proposed fix the right approach?
> >
> > I don't think the standard says anything about a string literal with the
> > same content as another literal having to share an address. I'd expect
> > that this is mainly optimization at the compiler or linker level. For
> > example, this:
> >
> >     const char* foo = "foobar";
> >     const char* bar = "bar";
> >
> > can be satisfied with this in the resulting binary:
> >
> >     "foobar\0"
> >      ^  ^
> >      |  bar
> >      foo
> >
> > but I'd expect the standard to say that doing `foo < bar` is always
> > undefined behavior since they're not pointers to the same object.
> >
> > > const char *cname = "vtkCommand or subclass";
> > >
> > > //----------------------------------------------------------------
> > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
> > > {
> > > #ifdef VTK_DEBUG_LEAKS
> > > vtkDebugLeaks::ConstructClass(cname);
> > > #endif
> > > }
> > >
> > > //----------------------------------------------------------------
> > > void vtkCommand::UnRegister()
> > > {
> > > int refcount = this->GetReferenceCount()-1;
> > > this->SetReferenceCount(refcount);
> > > if (refcount <= 0)
> > > {
> > > #ifdef VTK_DEBUG_LEAKS
> > > vtkDebugLeaks::DestructClass(cname);
> > > #endif
> > > delete this;
> > > }
> > > }
> >
> > This looks reasonable to me. Maybe add `static`?
> >
> > --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://vtk.org/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://vtk.org/mailman/listinfo/vtk-developers
>

From julien.finet at kitware.com  Tue Jan  8 03:24:43 2019
From: julien.finet at kitware.com (Julien Finet)
Date: Tue, 8 Jan 2019 09:24:43 +0100
Subject: [vtk-developers] DebugLeaks C++ expert issue?
In-Reply-To: <CAE-7VJmkh577a3BN6us0be1wibi4cawvgi-FBof_9KZGJOq_Lw@mail.gmail.com>
References: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
 <20190107165907.GA2027@megas.kitware.com>
 <CAKME8fH1YagDssVcrQN-_tN-DLMja7_6h96oTUV1ynG0ehuDCQ@mail.gmail.com>
 <CAE-7VJmkh577a3BN6us0be1wibi4cawvgi-FBof_9KZGJOq_Lw@mail.gmail.com>
Message-ID: <CAKoWPPHGgZyitmCkLC2yYK_eVzOOZJxFq0fQ8_v1RGNVzwz4NA@mail.gmail.com>

>From https://timsong-cpp.github.io/cppwp/lex.string#15:
    *whether successive evaluations of a string-literal yield the same or a
different object is unspecified  *


On Mon, Jan 7, 2019 at 9:52 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> Den m?n 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers
> <vtk-developers at vtk.org>:
> >
> > Is it built with the /GF compiler flag?
> >
> >
> https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017
>
> (Also note that flag is in effect when /O1 or /O2 is used)
>
> >
> >
> > On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers
> > <vtk-developers at vtk.org> wrote:
> > >
> > > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers
> wrote:
> > > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks
> is
> > > > complaining about vtkCommands being leaked because the two string
> literals
> > > > in the below code have different addresses (the string address is
> used in a
> > > > map type structure). Looking at DebugLeaks the only way this code
> would
> > > > work is if they have the same address. But I checked in the debugger
> and
> > > > they have different addresses.
> > > >
> > > > <snip>
> > > >
> > > > I can fix it by doing the following but wanted a c++ expert to weigh
> in,
> > > > was the original code OK? Is this a compiler compliance issue? Is the
> > > > proposed fix the right approach?
> > >
> > > I don't think the standard says anything about a string literal with
> the
> > > same content as another literal having to share an address. I'd expect
> > > that this is mainly optimization at the compiler or linker level. For
> > > example, this:
> > >
> > >     const char* foo = "foobar";
> > >     const char* bar = "bar";
> > >
> > > can be satisfied with this in the resulting binary:
> > >
> > >     "foobar\0"
> > >      ^  ^
> > >      |  bar
> > >      foo
> > >
> > > but I'd expect the standard to say that doing `foo < bar` is always
> > > undefined behavior since they're not pointers to the same object.
> > >
> > > > const char *cname = "vtkCommand or subclass";
> > > >
> > > > //----------------------------------------------------------------
> > > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
> > > > {
> > > > #ifdef VTK_DEBUG_LEAKS
> > > > vtkDebugLeaks::ConstructClass(cname);
> > > > #endif
> > > > }
> > > >
> > > > //----------------------------------------------------------------
> > > > void vtkCommand::UnRegister()
> > > > {
> > > > int refcount = this->GetReferenceCount()-1;
> > > > this->SetReferenceCount(refcount);
> > > > if (refcount <= 0)
> > > > {
> > > > #ifdef VTK_DEBUG_LEAKS
> > > > vtkDebugLeaks::DestructClass(cname);
> > > > #endif
> > > > delete this;
> > > > }
> > > > }
> > >
> > > This looks reasonable to me. Maybe add `static`?
> > >
> > > --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://vtk.org/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://vtk.org/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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/8ba73b36/attachment.html>

From mathieu.westphal at kitware.com  Tue Jan  8 08:32:28 2019
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Tue, 8 Jan 2019 14:32:28 +0100
Subject: [vtk-developers] [vtkusers] ANN: VTK Examples Project reaches
 1000 C++ Examples
In-Reply-To: <519751009.8376746.1546949350881@mail.yahoo.com>
References: <CADZJ4hO1Va3nM=pNLSvQ-4f8nQ2X-mP9tAscH7RPDEqfguHf4Q@mail.gmail.com>
 <519751009.8376746.1546949350881@mail.yahoo.com>
Message-ID: <CAC2t4USvKSdBCN60CtkhGJmTpgt2SG=71kUvf_PznEWn5cdPJQ@mail.gmail.com>

Hi Leonid,

I've forwarded you the message sent to the mailing list "the New
QVTKOpenGLWidget" on August 23 2018.
As usual, tests can be found in the source code of VTK for these specific
classes.

Best,

Mathieu Westphal


On Tue, Jan 8, 2019 at 1:09 PM Leonid Dulman via vtkusers <vtkusers at vtk.org>
wrote:

> Hi to All
> I'm looking for examples how to use new classes
>
> QVTKOpenGLWindow QVTKOpenGLNativeWidget  QVTKInteractorAdapter and how to
> use new classes instead of QVTKWidget2
> Thank you. Leonid
>
>
> ------------------------------
> *From:* Bill Lorensen <bill.lorensen at gmail.com>
> *To:* VTK Developers <vtk-developers at vtk.org>; VTK Users <vtkusers at vtk.org>
>
> *Sent:* Saturday, December 15, 2018 1:32 AM
> *Subject:* [vtkusers] ANN: VTK Examples Project reaches 1000 C++ Examples
>
> Folks,
>
> We have reached a milestone in the VTK Examples Project
> (https://lorensen.github.io/VTKExamples/site/). There are now 1000 C++
> examples (https://lorensen.github.io/VTKExamples/site/Cxx/).  The
> total number of examples is now almost 1500 with  1000 C++ examples,
> 121  CSharp examples (https://lorensen.github.io/VTKExamples/site/CSharp/
> ),
> 290 Python examples (https://lorensen.github.io/VTKExamples/site/Python/),
> and
> 41 Java examples (https://lorensen.github.io/VTKExamples/site/Java/).
>
> The number of Java examples is expanding thanks to our new contributor
> Bharatesh Chakravarthi from the VE Lab, Chung Ang University, Seoul,
> South Korea.  Bharatesh has quickly learned our example contribution
> process and has added over 20 examples. We expect to see many more
> Java examples in the coming months. We are always looking to new
> contributors (
> https://lorensen.github.io/VTKExamples/site/Instructions/ForDevelopers/.
>
> As a reminder, the VTK Example Project also hosts a latex version and
> markdown version of the VTK Textbook. The latex version is an improved
> version of the current VTK Textbook
> (
> https://raw.githubusercontent.com/lorensen/VTKExamples/master/src/VTKBookLaTeX/VTKTextBook.pdf
> ).
> The markdown version is an interactive, platform friendly version of
> the book (https://lorensen.github.io/VTKExamples/site/VTKBook/00Preface/).
>
>
> --
> Unpaid intern in BillsParadise at noware dot com
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtkusers
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/5ef973f4/attachment-0001.html>

From ken.martin at kitware.com  Tue Jan  8 08:42:11 2019
From: ken.martin at kitware.com (Ken Martin)
Date: Tue, 8 Jan 2019 08:42:11 -0500
Subject: [vtk-developers] DebugLeaks C++ expert issue?
In-Reply-To: <CAKoWPPHGgZyitmCkLC2yYK_eVzOOZJxFq0fQ8_v1RGNVzwz4NA@mail.gmail.com>
References: <CANXz0SatgQmMKigps0bKGHQtEPTZMExW3dCujtoQsf0Do+CMvQ@mail.gmail.com>
 <20190107165907.GA2027@megas.kitware.com>
 <CAKME8fH1YagDssVcrQN-_tN-DLMja7_6h96oTUV1ynG0ehuDCQ@mail.gmail.com>
 <CAE-7VJmkh577a3BN6us0be1wibi4cawvgi-FBof_9KZGJOq_Lw@mail.gmail.com>
 <CAKoWPPHGgZyitmCkLC2yYK_eVzOOZJxFq0fQ8_v1RGNVzwz4NA@mail.gmail.com>
Message-ID: <CANXz0Sa=YKnEZfNLmZ=iZ-CLnP7aNgrL_MHxOv9n4sik4yDzwA@mail.gmail.com>

Yes, the code has been there for ages so it seems that 99.9% of the time
the two string literals share storage. I'm not sure if it is a cmake change
or a vs2017 change (I updated both) that caused the issue to pop up. It is
a debug build with DEBUG_LEAKS turned on. But forcing them to share the
same address definitely solved the problem and seems that safe approach
from a standards point of view.

On Tue, Jan 8, 2019 at 3:25 AM Julien Finet <julien.finet at kitware.com>
wrote:

> From https://timsong-cpp.github.io/cppwp/lex.string#15:
>     *whether successive evaluations of a string-literal yield the same or
> a different object is unspecified  *
>
>
> On Mon, Jan 7, 2019 at 9:52 PM Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
>
>> Den m?n 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers
>> <vtk-developers at vtk.org>:
>> >
>> > Is it built with the /GF compiler flag?
>> >
>> >
>> https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017
>>
>> (Also note that flag is in effect when /O1 or /O2 is used)
>>
>> >
>> >
>> > On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers
>> > <vtk-developers at vtk.org> wrote:
>> > >
>> > > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers
>> wrote:
>> > > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue.
>> DebugLeaks is
>> > > > complaining about vtkCommands being leaked because the two string
>> literals
>> > > > in the below code have different addresses (the string address is
>> used in a
>> > > > map type structure). Looking at DebugLeaks the only way this code
>> would
>> > > > work is if they have the same address. But I checked in the
>> debugger and
>> > > > they have different addresses.
>> > > >
>> > > > <snip>
>> > > >
>> > > > I can fix it by doing the following but wanted a c++ expert to
>> weigh in,
>> > > > was the original code OK? Is this a compiler compliance issue? Is
>> the
>> > > > proposed fix the right approach?
>> > >
>> > > I don't think the standard says anything about a string literal with
>> the
>> > > same content as another literal having to share an address. I'd expect
>> > > that this is mainly optimization at the compiler or linker level. For
>> > > example, this:
>> > >
>> > >     const char* foo = "foobar";
>> > >     const char* bar = "bar";
>> > >
>> > > can be satisfied with this in the resulting binary:
>> > >
>> > >     "foobar\0"
>> > >      ^  ^
>> > >      |  bar
>> > >      foo
>> > >
>> > > but I'd expect the standard to say that doing `foo < bar` is always
>> > > undefined behavior since they're not pointers to the same object.
>> > >
>> > > > const char *cname = "vtkCommand or subclass";
>> > > >
>> > > > //----------------------------------------------------------------
>> > > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
>> > > > {
>> > > > #ifdef VTK_DEBUG_LEAKS
>> > > > vtkDebugLeaks::ConstructClass(cname);
>> > > > #endif
>> > > > }
>> > > >
>> > > > //----------------------------------------------------------------
>> > > > void vtkCommand::UnRegister()
>> > > > {
>> > > > int refcount = this->GetReferenceCount()-1;
>> > > > this->SetReferenceCount(refcount);
>> > > > if (refcount <= 0)
>> > > > {
>> > > > #ifdef VTK_DEBUG_LEAKS
>> > > > vtkDebugLeaks::DestructClass(cname);
>> > > > #endif
>> > > > delete this;
>> > > > }
>> > > > }
>> > >
>> > > This looks reasonable to me. Maybe add `static`?
>> > >
>> > > --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://vtk.org/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://vtk.org/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://vtk.org/mailman/listinfo/vtk-developers
>>
>>

-- 
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/bac04b08/attachment.html>

From ben.boeckel at kitware.com  Tue Jan  8 08:52:50 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Jan 2019 08:52:50 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190103201622.GA11008@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190103201622.GA11008@rotor.localdomain>
Message-ID: <20190108135249.GA17126@megas.kitware.com>

On Thu, Jan 03, 2019 at 15:16:22 -0500, Ben Boeckel wrote:
> On Wed, Jan 02, 2019 at 14:23:53 -0500, Ben Boeckel wrote:
> > The new module system is in a landable state right now. We're planning
> > on merging it Friday (4 Jan 2019).
> 
> This has been delayed until at least Monday afternoon.

It has now been merged.

Buildbots will be a little rocky until their module set is minimized to
those they can actually build. I hope to make decent progress on that
today.

--Ben

From ben.boeckel at kitware.com  Tue Jan  8 11:56:48 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Jan 2019 11:56:48 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190102192353.GA24527@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
Message-ID: <20190108165648.GA24126@megas.kitware.com>

On Wed, Jan 02, 2019 at 14:23:53 -0500, Ben Boeckel wrote:
>       - `Module_<MMM>` -> `VTK_MODULE_ENABLE_<MMM>`
>       - `VTK_USE_SYSTEM_<MMM>` -> `VTK_MODULE_USE_EXTERNAL_<MMM>`

So after some fiddling around with Buildbot, it turns out that putting
`::` in cache variable names makes it really hard to pass them on the
command line. The cache variables have `::` replaced with `_`.

The buildbot cleanup work is ongoing in:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5039

--Ben

From david.gobbi at gmail.com  Tue Jan  8 12:00:32 2019
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 8 Jan 2019 10:00:32 -0700
Subject: [vtk-developers] New cmake modules: TBB broken?
Message-ID: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>

Hi Ben,

The new FindTBB.cmake is broken, specifically in this section starting at
line 88:

set_target_propertes(TBB::${TARGET} PROPERTIES
      IMPORTED_LOCATION "${${PREFIX}_LIBRARY}"
      IMPORTED_LOCATION_DEBUG "${${PREFIX}_LIBRARY_DEBUG}"
      IMPORTED_LOCATION_RELEASE "${${PREFIX}_LIBRARY_RELEASE}")
target_include_directories(TBB::${TARGET} INTERFACE
"${${PREFIX}_INCLUDE_DIR}")

There is an error for the "set_target_properties" typo, and these errors
for "target_include_directories":

==
target_include_directories called with non-compilable target type
==
add_library cannot create imported target "TBB::" because another target
  with the same name already exists.
==

  - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/5dc7ab13/attachment.html>

From ben.boeckel at kitware.com  Tue Jan  8 13:16:00 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Jan 2019 13:16:00 -0500
Subject: [vtk-developers] New cmake modules: TBB broken?
In-Reply-To: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>
References: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>
Message-ID: <20190108181600.GB24126@megas.kitware.com>

On Tue, Jan 08, 2019 at 10:00:32 -0700, David Gobbi wrote:
> The new FindTBB.cmake is broken, specifically in this section starting at
> line 88:
> 
> set_target_propertes(TBB::${TARGET} PROPERTIES
>       IMPORTED_LOCATION "${${PREFIX}_LIBRARY}"
>       IMPORTED_LOCATION_DEBUG "${${PREFIX}_LIBRARY_DEBUG}"
>       IMPORTED_LOCATION_RELEASE "${${PREFIX}_LIBRARY_RELEASE}")
> target_include_directories(TBB::${TARGET} INTERFACE
> "${${PREFIX}_INCLUDE_DIR}")
> 
> There is an error for the "set_target_properties" typo, and these errors
> for "target_include_directories":

I'm working on a followup branch here:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5039

--Ben

From ben.boeckel at kitware.com  Tue Jan  8 14:21:09 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Jan 2019 14:21:09 -0500
Subject: [vtk-developers] New cmake modules: TBB broken?
In-Reply-To: <457299346.2663950.1546968849853.JavaMail.zimbra@elemtech.com>
References: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>
 <457299346.2663950.1546968849853.JavaMail.zimbra@elemtech.com>
Message-ID: <20190108192109.GA8744@megas.kitware.com>

On Tue, Jan 08, 2019 at 10:34:09 -0700, clinton at elemtech.com wrote:
> I had similar problems with FindX11.cmake. 
> 
> I built VTK, then tried to use it in my application where I already have a find_package(X11), and it gave me tons of errors : 
> add_library cannot create imported target "X11::...." because another target with the same name already exists. 

Thanks for the report. Will guard the target creation with checks that
they don't already exist.

--Ben

From clinton at elemtech.com  Tue Jan  8 12:34:09 2019
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Tue, 8 Jan 2019 10:34:09 -0700 (MST)
Subject: [vtk-developers] New cmake modules: TBB broken?
In-Reply-To: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>
References: <CANwS1=H8F6QzWTD=56_cE0c3JuwFwESAsOznK8vmEDjz04Qwmw@mail.gmail.com>
Message-ID: <457299346.2663950.1546968849853.JavaMail.zimbra@elemtech.com>

I had similar problems with FindX11.cmake. 

I built VTK, then tried to use it in my application where I already have a find_package(X11), and it gave me tons of errors : 
add_library cannot create imported target "X11::...." because another target with the same name already exists. 

Clint 

----- On Jan 8, 2019, at 10:00 AM, David Gobbi <david.gobbi at gmail.com> wrote: 

> Hi Ben,

> The new FindTBB.cmake is broken, specifically in this section starting at line
> 88:
> set_target_propertes(TBB::${TARGET} PROPERTIES
> IMPORTED_LOCATION "${${PREFIX}_LIBRARY}"
> IMPORTED_LOCATION_DEBUG "${${PREFIX}_LIBRARY_DEBUG}"
> IMPORTED_LOCATION_RELEASE "${${PREFIX}_LIBRARY_RELEASE}")
> target_include_directories(TBB::${TARGET} INTERFACE "${${PREFIX}_INCLUDE_DIR}")

> There is an error for the "set_target_properties" typo, and these errors for
> "target_include_directories":

> ==
> target_include_directories called with non-compilable target type
> ==
> add_library cannot create imported target "TBB::" because another target
> with the same name already exists.
> ==

> - David

> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/75e3fd43/attachment.html>

From ben.boeckel at kitware.com  Tue Jan  8 18:11:54 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Jan 2019 18:11:54 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190108165648.GA24126@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
Message-ID: <20190108231154.GA29838@megas.kitware.com>

On Tue, Jan 08, 2019 at 11:56:48 -0500, Ben Boeckel wrote:
> On Wed, Jan 02, 2019 at 14:23:53 -0500, Ben Boeckel wrote:
> >       - `Module_<MMM>` -> `VTK_MODULE_ENABLE_<MMM>`
> >       - `VTK_USE_SYSTEM_<MMM>` -> `VTK_MODULE_USE_EXTERNAL_<MMM>`
> 
> So after some fiddling around with Buildbot, it turns out that putting
> `::` in cache variable names makes it really hard to pass them on the
> command line. The cache variables have `::` replaced with `_`.
> 
> The buildbot cleanup work is ongoing in:
> 
>     https://gitlab.kitware.com/vtk/vtk/merge_requests/5039

This MR has now been merged. The buildbots are building code at least.
I'll work on cleaning up the warnings in the coming days with third
party patches and sending the relevant ones upstream.

Current state of test failures:

  - taanab and adora: CMake is warning about the inability to make
    fully correct rpath variables for targets. There may be a way to fix
    this, but it may be up to doing a suppression as well.
  - duma: it should be using OSMesa, but is not.
  - example tests: Examples aren't downloading example data properly.
  - various machines: since freetype has been updated, it seems that
    some new baselines will need to be added. I'll do that as well, but
    feel free to grab some if you want.
  - mun: static build failure with jsoncpp symbols. Will look into this
    tomorrow.
  - mun: shared+kits Python tests are failing. I suspect a missing PATH
    entry or the like. Will investgate tomorrow.

Buildbots are now building all modules allowed by their configuration.
Here is a list of modules that are explicitly disabled on machines
(usually due to lacking CUDA, Boost, or other dependency) that would
otherwise build due to the configuration[1]:

    1         'VTK_MODULE_ENABLE_VTK_GUISupportMFC:STRING': 'NO',
    1         'VTK_MODULE_ENABLE_VTK_IOOpenTurns:STRING': 'NO',
    4         'VTK_MODULE_ENABLE_VTK_RenderingExternal:STRING': 'NO',
    5         'VTK_MODULE_ENABLE_VTK_FiltersReebGraph:STRING': 'NO',
    5         'VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms:STRING': 'NO',
    5         'VTK_MODULE_ENABLE_VTK_IOADIOS:STRING': 'NO',
    5         'VTK_MODULE_ENABLE_VTK_xdmf3:STRING': 'NO',
    6         'VTK_MODULE_ENABLE_VTK_IOLAS:STRING': 'NO',
    6         'VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig:STRING': 'NO',
    7         'VTK_MODULE_ENABLE_VTK_DomainsMicroscopy:STRING': 'NO',
    7         'VTK_MODULE_ENABLE_VTK_InfovisBoost:STRING': 'NO',
    7         'VTK_MODULE_ENABLE_VTK_IOFFMPEG:STRING': 'NO',
    7         'VTK_MODULE_ENABLE_VTK_IOGDAL:STRING': 'NO',
    7         'VTK_MODULE_ENABLE_VTK_IOODBC:STRING': 'NO',
    8         'VTK_MODULE_ENABLE_VTK_FiltersOpenTurns:STRING': 'NO',
    8         'VTK_MODULE_ENABLE_VTK_IOMySQL:STRING': 'NO',
    8         'VTK_MODULE_ENABLE_VTK_IOPDAL:STRING': 'NO',
    8         'VTK_MODULE_ENABLE_VTK_IOPostgreSQL:STRING': 'NO',
    9         'VTK_MODULE_ENABLE_VTK_RenderingOpenVR:STRING': 'NO',
    9         'VTK_MODULE_ENABLE_VTK_RenderingOptiX:STRING': 'NO',

Note that there are 9 machines, so OpenVR and OptiX are currently completely
untested on the buildbots. If these modules should be more widely
tested, feel free to open an issue for the module and which
machines/configurations should be building it and we can try and get the
dependencies installed.

Turnaround times for builds for a from-scratch build:

                configure   build   test    total   prior total
adora:          1:44        19:09  55:55    76:48   29:46
bigmac:         2:22        17:17   5:49    25:28   30:57
dejagore:       <busy with vtk-m>                   54:18
duma:           0:49        14:27  12:00    27:16   17:48
eeloo:
  +extdeps:     1:42        30:22   2:55    34:59   37:23
  +nogl:        0:49        13:45   0:13    14:47   17:54
luigi:          1:40        33:41   5:03    40:24   42:26
mun:
  (no kits):    3:15        12:38   5:38    21:31   35:15
  static:       3:20        <fails>                 39:45
  +kits:        3:19        8:29    3:55    15:43   34:55
taanab:         2:21        11:50   1:59    16:10   16:34
trey:           2:30        33:50   8:10    44:30   43:09

Note that builds are (generally) building more modules and tests than
before. From this analysis, I'm seeing that the eeloo+nogl builder has
270 tests versus the master's 807 tests, but this may be due to
dependency specifications being different. mun without kits is also
missing ~800 or so tests. adora's abysmal test time is due to timeouts
on the machine; I am seeing some X-related errors and they all seem to
be Python tests as well. dejagore is currently busy with `vtk-m`
testing, but I'm headed out for the day, so I'll leave it for tomorrow.

--Ben

[1]For example, GUISupportMFC is only explicitly disabled on Windows
machines since it "hides" on non-Windows builds. Other modules are also
masked by things like `VTK_USE_MPI`, `VTK_WRAP_PYTHON`, or platform
checks.

From ben.boeckel at kitware.com  Wed Jan  9 09:24:00 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 09:24:00 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190108231154.GA29838@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
Message-ID: <20190109142400.GC32246@megas.kitware.com>

On Tue, Jan 08, 2019 at 18:11:54 -0500, Ben Boeckel wrote:
> Turnaround times for builds for a from-scratch build:

Filling this out with `dejagore`'s timing:

>                 configure   build   test    total   prior total
> adora:          1:44        19:09  55:55    76:48   29:46
> bigmac:         2:22        17:17   5:49    25:28   30:57
dejagore:         2:38        32:38   9:35    44:51   54:18
> duma:           0:49        14:27  12:00    27:16   17:48
> eeloo:
>   +extdeps:     1:42        30:22   2:55    34:59   37:23
>   +nogl:        0:49        13:45   0:13    14:47   17:54
> luigi:          1:40        33:41   5:03    40:24   42:26
> mun:
>   (no kits):    3:15        12:38   5:38    21:31   35:15
>   static:       3:20        <fails>                 39:45
>   +kits:        3:19        8:29    3:55    15:43   34:55
> taanab:         2:21        11:50   1:59    16:10   16:34
> trey:           2:30        33:50   8:10    44:30   43:09

--Ben

From david.gobbi at gmail.com  Wed Jan  9 12:45:39 2019
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 9 Jan 2019 10:45:39 -0700
Subject: [vtk-developers] Library names for new cmake modules
Message-ID: <CANwS1=GqF8SL+1eo+KovyGE_c=V2Tc4MMsWgtw9RWA6zpUnL+Q@mail.gmail.com>

Hi Ben,

The new module system changes the so library names.  Was this intentional?

On MacOS:

libvtkCommonCore-8.90.8.90.0.dylib
libvtkCommonCore-8.90.dylib -> libvtkCommonCore-8.90.1.dylib
libvtkCommonCore-8.90.1.dylib -> libvtkCommonCore-8.90.8.90.0.dylib

vs

libvtkCommonCore-8.2.1.dylib
libvtkCommonCore-8.2.dylib -> libvtkCommonCore-8.2.1.dylib

On Linux:

libvtkCommonCore-8.90.so.8.90.0
libvtkCommonCore-8.90.so -> libvtkCommonCore-8.90.so.1
libvtkCommonCore-8.90.so.1 -> libvtkCommonCore-8.90.so.8.90.0

vs

libvtkCommonCore-8.2.so.1
libvtkCommonCore-8.2.so -> libvtkCommonCore-8.2.so.1

On an unrelated note, CMAKE_BUILD_TYPE=RelWithDebInfo causes duplicated
targets.

  David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/5d735065/attachment.html>

From ben.boeckel at kitware.com  Wed Jan  9 13:27:18 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 13:27:18 -0500
Subject: [vtk-developers] Library names for new cmake modules
In-Reply-To: <CANwS1=GqF8SL+1eo+KovyGE_c=V2Tc4MMsWgtw9RWA6zpUnL+Q@mail.gmail.com>
References: <CANwS1=GqF8SL+1eo+KovyGE_c=V2Tc4MMsWgtw9RWA6zpUnL+Q@mail.gmail.com>
Message-ID: <20190109182718.GB23420@megas.kitware.com>

On Wed, Jan 09, 2019 at 10:45:39 -0700, David Gobbi wrote:
> The new module system changes the so library names.  Was this intentional?

<snip>

Hmm, this is probably because SOVERSION is now set. Maybe we shouldn't
do that?

> On an unrelated note, CMAKE_BUILD_TYPE=RelWithDebInfo causes duplicated
> targets.

Ooh, I hadn't seen that. Will investigate. What duplicate targets are
you seeing.

--Ben

From david.gobbi at gmail.com  Wed Jan  9 13:36:41 2019
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 9 Jan 2019 11:36:41 -0700
Subject: [vtk-developers] Library names for new cmake modules
In-Reply-To: <20190109182718.GB23420@megas.kitware.com>
References: <CANwS1=GqF8SL+1eo+KovyGE_c=V2Tc4MMsWgtw9RWA6zpUnL+Q@mail.gmail.com>
 <20190109182718.GB23420@megas.kitware.com>
Message-ID: <CANwS1=G0yRS9KQ3F_pWjZvgQdmd5OPLhstNpRSEJCHUXibqb_A@mail.gmail.com>

On Wed, Jan 9, 2019 at 11:27 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

>
> Hmm, this is probably because SOVERSION is now set. Maybe we shouldn't
> do that?
>

Since the version number is part of the base name, SOVERSION is redundant.


> On an unrelated note, CMAKE_BUILD_TYPE=RelWithDebInfo causes duplicated
> > targets.
>
> Ooh, I hadn't seen that. Will investigate. What duplicate targets are
> you seeing.
>

With RelWithDebInfo, I get these errors (might not actually be a dup
target):

Common/Core/CMakeFiles/CommonCore.dir/build.make:2026: warning: overriding
commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
Common/Core/CMakeFiles/CommonCore.dir/build.make:2024: warning: ignoring
old commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
Common/Core/CMakeFiles/CommonCore.dir/build.make:2026: warning: overriding
commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
Common/Core/CMakeFiles/CommonCore.dir/build.make:2024: warning: ignoring
old commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
make[2]: *** No rule to make target `optimized', needed by
`lib/libvtkCommonCore-8.90.8.90.0.dylib'.  Stop.

  David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/17ccf130/attachment.html>

From ben.boeckel at kitware.com  Wed Jan  9 13:49:00 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 13:49:00 -0500
Subject: [vtk-developers] Library names for new cmake modules
In-Reply-To: <CANwS1=G0yRS9KQ3F_pWjZvgQdmd5OPLhstNpRSEJCHUXibqb_A@mail.gmail.com>
References: <CANwS1=GqF8SL+1eo+KovyGE_c=V2Tc4MMsWgtw9RWA6zpUnL+Q@mail.gmail.com>
 <20190109182718.GB23420@megas.kitware.com>
 <CANwS1=G0yRS9KQ3F_pWjZvgQdmd5OPLhstNpRSEJCHUXibqb_A@mail.gmail.com>
Message-ID: <20190109184900.GC23420@megas.kitware.com>

On Wed, Jan 09, 2019 at 11:36:41 -0700, David Gobbi wrote:
> On Wed, Jan 9, 2019 at 11:27 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:
> > Hmm, this is probably because SOVERSION is now set. Maybe we shouldn't
> > do that?
> 
> Since the version number is part of the base name, SOVERSION is redundant.

Sorry, not `SOVERSION` (which turns into ELF's `SONAME`). Removing
`VERSION ${VTK_VERSION}` in CMakeLists.txt should do it here.

> > On an unrelated note, CMAKE_BUILD_TYPE=RelWithDebInfo causes duplicated
> > > targets.
> >
> > Ooh, I hadn't seen that. Will investigate. What duplicate targets are
> > you seeing.
> >
> 
> With RelWithDebInfo, I get these errors (might not actually be a dup
> target):
> 
> Common/Core/CMakeFiles/CommonCore.dir/build.make:2026: warning: overriding
> commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
> Common/Core/CMakeFiles/CommonCore.dir/build.make:2024: warning: ignoring
> old commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
> Common/Core/CMakeFiles/CommonCore.dir/build.make:2026: warning: overriding
> commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
> Common/Core/CMakeFiles/CommonCore.dir/build.make:2024: warning: ignoring
> old commands for target `lib/libvtkCommonCore-8.90.8.90.0.dylib'
> make[2]: *** No rule to make target `optimized', needed by
> `lib/libvtkCommonCore-8.90.8.90.0.dylib'.  Stop.

Odd. I suspect these go away with the `VERSION` argument as well. The
`optimized` points to something else going wrong with a find module.

--Ben

From bill.lorensen at gmail.com  Wed Jan  9 14:44:01 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 9 Jan 2019 11:44:01 -0800
Subject: [vtk-developers] FindPackage not working in new module system
Message-ID: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>

TYhis cmake file:
cmake_minimum_required(VERSION 2.8)

PROJECT(ReadOBJ)

find_package(VTK REQUIRED)
include(${VTK_USE_FILE})

add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )

target_link_libraries(ReadOBJ ${VTK_LIBRARIES})

I specify the VTK_DIR to point at a new module VTK build. I'm using
cmake version 3.10.3

I get:

CMake Error at /usr/share/cmake-2.8/Modules/FindVTK.cmake:135 (message):
  VTK not found.  Set the VTK_DIR cmake cache entry to the directory
  containing VTKConfig.cmake.  This is either the root of the build tree, or
  PREFIX/lib/vtk for an installation.  For VTK 4.0, this is the location of
  UseVTK.cmake.  This is either the root of the build tree or
  PREFIX/include/vtk for an installation.
Call Stack (most recent call first):
  CMakeLists.txt:6 (find_package)

-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Wed Jan  9 15:06:40 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 15:06:40 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
Message-ID: <20190109200640.GA24952@megas.kitware.com>

On Wed, Jan 09, 2019 at 11:44:01 -0800, Bill Lorensen wrote:
> TYhis cmake file:
> cmake_minimum_required(VERSION 2.8)
> 
> PROJECT(ReadOBJ)
> 
> find_package(VTK REQUIRED)
> include(${VTK_USE_FILE})
> 
> add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> 
> target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
> 
> I specify the VTK_DIR to point at a new module VTK build. I'm using
> cmake version 3.10.3

The vtk-config.cmake file is in the `lib/cmake/vtk-*` directory of the
build tree, not the top-level. This mirrors the install tree and also
keeps the code between the two very similar (instead of having to differ
on relative paths to other generated CMake files).

--Ben

From kyle.edwards at kitware.com  Wed Jan  9 15:19:29 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 09 Jan 2019 15:19:29 -0500
Subject: [vtk-developers] WebAssembly Support
Message-ID: <1547065169.4676.51.camel@kitware.com>

Hello all,

A while back, I tried buliding a minimal subset of VTK with Emscripten,
the WebAssembly compiler, but it failed to compile because VTK uses
features that are not in OpenGL ES2. Does anyone here have an idea of
how much work would be needed to port VTK to ES2? (This is not related
to vtk.js. This is an attempt to compile VTK proper from C++ to
WebAssembly.)

Kyle

From dave.demarle at kitware.com  Wed Jan  9 16:01:29 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 9 Jan 2019 16:01:29 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <1547065169.4676.51.camel@kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
Message-ID: <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>

Hey Kyle, are you working with Matt McCormick?

When we were WebAssembling VTK last year, they chose to strip disable
rendering, one reason being that we already have good support for rendering
on the web via vtk.js.

I also believe that we dropped ES2 support a release or two ago. Ken Martin
can confirm that.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Wed, Jan 9, 2019 at 3:19 PM Kyle Edwards via vtk-developers <
vtk-developers at vtk.org> wrote:

> Hello all,
>
> A while back, I tried buliding a minimal subset of VTK with Emscripten,
> the WebAssembly compiler, but it failed to compile because VTK uses
> features that are not in OpenGL ES2. Does anyone here have an idea of
> how much work would be needed to port VTK to ES2? (This is not related
> to vtk.js. This is an attempt to compile VTK proper from C++ to
> WebAssembly.)
>
> Kyle
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/dea5c94a/attachment.html>

From kyle.edwards at kitware.com  Wed Jan  9 16:06:42 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 09 Jan 2019 16:06:42 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>
References: <1547065169.4676.51.camel@kitware.com>
 <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>
Message-ID: <1547068002.4676.54.camel@kitware.com>

On Wed, 2019-01-09 at 16:01 -0500, David E DeMarle wrote:
> Hey Kyle, are you working with Matt McCormick?
No, this is for the vision team.
> When we were WebAssembling VTK last year, they chose to strip disable rendering, one reason being that we already have good support for rendering on the web via vtk.js.
> > I also believe that we dropped ES2 support a release or two ago. Ken
> Martin can confirm that.
I thought ES2 was needed to support Android and iOS. Does VTK still
support them? Do they allow full OpenGL instead of just ES?
Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/b5781896/attachment.html>

From dave.demarle at kitware.com  Wed Jan  9 16:09:36 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 9 Jan 2019 16:09:36 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <1547068002.4676.54.camel@kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
 <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>
 <1547068002.4676.54.camel@kitware.com>
Message-ID: <CANjZAi-xC+B=sqswmRKA7mTU5tfgWNZ8XYs-5v0QtFDEK83XxQ@mail.gmail.com>

ES3 support is active.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Wed, Jan 9, 2019 at 4:06 PM Kyle Edwards <kyle.edwards at kitware.com>
wrote:

> On Wed, 2019-01-09 at 16:01 -0500, David E DeMarle wrote:
>
> Hey Kyle, are you working with Matt McCormick?
>
>
> No, this is for the vision team.
>
> When we were WebAssembling VTK last year, they chose to strip disable
> rendering, one reason being that we already have good support for rendering
> on the web via vtk.js.
>
> I also believe that we dropped ES2 support a release or two ago. Ken
> Martin can confirm that.
>
>
> I thought ES2 was needed to support Android and iOS. Does VTK still
> support them? Do they allow full OpenGL instead of just ES?
>
> Kyle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/e986081e/attachment.html>

From aron.helser at kitware.com  Wed Jan  9 16:11:54 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Wed, 9 Jan 2019 16:11:54 -0500
Subject: [vtk-developers] OpenVR compile error with new module system
Message-ID: <CAF2skS7VVanXy_qgpRpGJfnLA=JLpFhztA8NCUd6ofuz3aLJdw@mail.gmail.com>

I found a typo in the OpenVR cmake:

diff --git a/Rendering/OpenVR/CMakeLists.txt
b/Rendering/OpenVR/CMakeLists.txt
index a091afc3ce..810b062005 100644
--- a/Rendering/OpenVR/CMakeLists.txt
+++ b/Rendering/OpenVR/CMakeLists.txt
@@ -49,8 +49,8 @@ foreach (geometry_file IN LISTS geometry_files)
     SOURCE_OUTPUT source
     BINARY
     NUL_TERMINATE)
-  list(APPEND sources "${source}")
-  list(APPEND headers "${source}")
+  list(APPEND geometry_sources "${source}")
+  list(APPEND geometry_headers "${header}")
 endforeach ()

After this fix, I still get a related error:

ninja: error:
'C:/akit/vtk/src/Rendering/OpenVR/vtkAvatarHead.h', needed by
'lib/vtk/hierarchy/VTK/vtkRenderingOpenVR-hierarchy.txt', missing and no
known rule to make it

I'm not sure about this .txt file or what to do next?

Thanks,
Aron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/3fc132cf/attachment.html>

From kyle.edwards at kitware.com  Wed Jan  9 16:14:02 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 09 Jan 2019 16:14:02 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <CANjZAi-xC+B=sqswmRKA7mTU5tfgWNZ8XYs-5v0QtFDEK83XxQ@mail.gmail.com>
References: <1547065169.4676.51.camel@kitware.com>
 <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>
 <1547068002.4676.54.camel@kitware.com>
 <CANjZAi-xC+B=sqswmRKA7mTU5tfgWNZ8XYs-5v0QtFDEK83XxQ@mail.gmail.com>
Message-ID: <1547068442.4676.57.camel@kitware.com>

Ah, my mistake. I didn't realize you meant that only version 2 had been
dropped - I thought you meant ES support had been dropped entirely.
So if ES3 is supported, what would be needed to activate it in
WebAssembly? Would it be a matter of adding a new mobile platform type,
similar to Android and iOS? Would I just need to edit the CMake scripts
to turn on some build flags, or would more work need to be done in the
OpenGL code itself?
Kyle
On Wed, 2019-01-09 at 16:09 -0500, David E DeMarle wrote:
> ES3 support is active.
> 
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 
> 
> On Wed, Jan 9, 2019 at 4:06 PM Kyle Edwards <kyle.edwards at kitware.com
> > wrote:
> > On Wed, 2019-01-09 at 16:01 -0500, David E DeMarle wrote:
> > > Hey Kyle, are you working with Matt McCormick?
> > No, this is for the vision team.
> > 
> > > When we were WebAssembling VTK last year, they chose to strip
> > > disable rendering, one reason being that we already have good
> > > support for rendering on the web via vtk.js.
> > > 
> > > I also believe that we dropped ES2 support a release or two ago.
> > > Ken Martin can confirm that.
> > I thought ES2 was needed to support Android and iOS. Does VTK still
> > support them? Do they allow full OpenGL instead of just ES?
> > 
> > Kyle
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/ebdc3d67/attachment.html>

From dave.demarle at kitware.com  Wed Jan  9 16:16:03 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 9 Jan 2019 16:16:03 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <1547068442.4676.57.camel@kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
 <CANjZAi8Ee1+VPmD4OmJ5F3B07Et2gWtr3e8FSfFsVY0e0+4AXQ@mail.gmail.com>
 <1547068002.4676.54.camel@kitware.com>
 <CANjZAi-xC+B=sqswmRKA7mTU5tfgWNZ8XYs-5v0QtFDEK83XxQ@mail.gmail.com>
 <1547068442.4676.57.camel@kitware.com>
Message-ID: <CANjZAi-++qsAoKCipmnuZ7U_LmXpHau9Md=iCEDjNHx3n=aiMw@mail.gmail.com>

I think it will be just a new platform type as you suggest. Once the CMake
sets the right flags the rendering code will do the right thing.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Wed, Jan 9, 2019 at 4:14 PM Kyle Edwards <kyle.edwards at kitware.com>
wrote:

> Ah, my mistake. I didn't realize you meant that only version 2 had been
> dropped - I thought you meant ES support had been dropped entirely.
>
> So if ES3 is supported, what would be needed to activate it in
> WebAssembly? Would it be a matter of adding a new mobile platform type,
> similar to Android and iOS? Would I just need to edit the CMake scripts to
> turn on some build flags, or would more work need to be done in the OpenGL
> code itself?
>
> Kyle
>
> On Wed, 2019-01-09 at 16:09 -0500, David E DeMarle wrote:
>
> ES3 support is active.
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
>
>
> On Wed, Jan 9, 2019 at 4:06 PM Kyle Edwards <kyle.edwards at kitware.com>
> wrote:
>
> On Wed, 2019-01-09 at 16:01 -0500, David E DeMarle wrote:
>
> Hey Kyle, are you working with Matt McCormick?
>
>
> No, this is for the vision team.
>
> When we were WebAssembling VTK last year, they chose to strip disable
> rendering, one reason being that we already have good support for rendering
> on the web via vtk.js.
>
> I also believe that we dropped ES2 support a release or two ago. Ken
> Martin can confirm that.
>
>
> I thought ES2 was needed to support Android and iOS. Does VTK still
> support them? Do they allow full OpenGL instead of just ES?
>
> Kyle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/55eee155/attachment-0001.html>

From ben.boeckel at kitware.com  Wed Jan  9 16:16:17 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 16:16:17 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <1547065169.4676.51.camel@kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
Message-ID: <20190109211617.GA25386@megas.kitware.com>

On Wed, Jan 09, 2019 at 15:19:29 -0500, Kyle Edwards via vtk-developers wrote:
> A while back, I tried buliding a minimal subset of VTK with Emscripten,
> the WebAssembly compiler, but it failed to compile because VTK uses
> features that are not in OpenGL ES2. Does anyone here have an idea of
> how much work would be needed to port VTK to ES2? (This is not related
> to vtk.js. This is an attempt to compile VTK proper from C++ to
> WebAssembly.)

Brad did this at some point. What errors are you seeing? What are the
OpenGL-related settings (see Utilities/OpenGL/vtkOpenGLOptions.cmake)?

--Ben

From dave.demarle at kitware.com  Wed Jan  9 16:19:30 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 9 Jan 2019 16:19:30 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <20190109211617.GA25386@megas.kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
 <20190109211617.GA25386@megas.kitware.com>
Message-ID: <CANjZAi_zA_3z6-4b-DViA=Q_EmoZ5MFvByEXSi3DUBGcASwn1w@mail.gmail.com>

Looks like 7.1.1 was the last version with ES2 support. 8.0 went to only
ES3.

Definitely talk to Matt McCormick who worked with Brad and probably JC last
time.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Wed, Jan 9, 2019 at 4:16 PM Ben Boeckel via vtk-developers <
vtk-developers at vtk.org> wrote:

> On Wed, Jan 09, 2019 at 15:19:29 -0500, Kyle Edwards via vtk-developers
> wrote:
> > A while back, I tried buliding a minimal subset of VTK with Emscripten,
> > the WebAssembly compiler, but it failed to compile because VTK uses
> > features that are not in OpenGL ES2. Does anyone here have an idea of
> > how much work would be needed to port VTK to ES2? (This is not related
> > to vtk.js. This is an attempt to compile VTK proper from C++ to
> > WebAssembly.)
>
> Brad did this at some point. What errors are you seeing? What are the
> OpenGL-related settings (see Utilities/OpenGL/vtkOpenGLOptions.cmake)?
>
> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/66f969b7/attachment.html>

From kyle.edwards at kitware.com  Wed Jan  9 16:21:11 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Wed, 09 Jan 2019 16:21:11 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <20190109211617.GA25386@megas.kitware.com>
References: <1547065169.4676.51.camel@kitware.com>
 <20190109211617.GA25386@megas.kitware.com>
Message-ID: <1547068871.4676.60.camel@kitware.com>

On Wed, 2019-01-09 at 16:16 -0500, Ben Boeckel wrote:
> Brad did this at some point. What errors are you seeing? What are the
> OpenGL-related settings (see
> Utilities/OpenGL/vtkOpenGLOptions.cmake)?

This was a while ago, and I don't remember the details, but I know it
was attempting to use OpenGL functions that are not present in ES2/3.
Of course, this is probably because I hadn't actually told it to build
as ES3 - as you said, I will have to modify the CMake script to do
that.

Kyle

From ben.boeckel at kitware.com  Wed Jan  9 16:47:15 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 9 Jan 2019 16:47:15 -0500
Subject: [vtk-developers] OpenVR compile error with new module system
In-Reply-To: <CAF2skS7VVanXy_qgpRpGJfnLA=JLpFhztA8NCUd6ofuz3aLJdw@mail.gmail.com>
References: <CAF2skS7VVanXy_qgpRpGJfnLA=JLpFhztA8NCUd6ofuz3aLJdw@mail.gmail.com>
Message-ID: <20190109214715.GA11685@megas.kitware.com>

On Wed, Jan 09, 2019 at 16:11:54 -0500, Aron Helser wrote:
> I found a typo in the OpenVR cmake:
> 
> diff --git a/Rendering/OpenVR/CMakeLists.txt
> b/Rendering/OpenVR/CMakeLists.txt
> index a091afc3ce..810b062005 100644
> --- a/Rendering/OpenVR/CMakeLists.txt
> +++ b/Rendering/OpenVR/CMakeLists.txt
> @@ -49,8 +49,8 @@ foreach (geometry_file IN LISTS geometry_files)
>      SOURCE_OUTPUT source
>      BINARY
>      NUL_TERMINATE)
> -  list(APPEND sources "${source}")
> -  list(APPEND headers "${source}")
> +  list(APPEND geometry_sources "${source}")
> +  list(APPEND geometry_headers "${header}")
>  endforeach ()

Oops, indeed.

> After this fix, I still get a related error:
> 
> ninja: error:
> 'C:/akit/vtk/src/Rendering/OpenVR/vtkAvatarHead.h', needed by
> 'lib/vtk/hierarchy/VTK/vtkRenderingOpenVR-hierarchy.txt', missing and no
> known rule to make it
> 
> I'm not sure about this .txt file or what to do next?

It means that a header named `vtkAvatarHead.h` is expected to be in the
build tree?it isn't. I suspect the `vtkAvatar*` listings in `classes`
should just be removed.

Please feel free to open an MR; I don't have OpenVR here at the moment
to test against.

--Ben

From matt.mccormick at kitware.com  Wed Jan  9 17:28:37 2019
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 9 Jan 2019 17:28:37 -0500
Subject: [vtk-developers] WebAssembly Support
In-Reply-To: <CANjZAi_zA_3z6-4b-DViA=Q_EmoZ5MFvByEXSi3DUBGcASwn1w@mail.gmail.com>
References: <1547065169.4676.51.camel@kitware.com>
 <20190109211617.GA25386@megas.kitware.com>
 <CANjZAi_zA_3z6-4b-DViA=Q_EmoZ5MFvByEXSi3DUBGcASwn1w@mail.gmail.com>
Message-ID: <CALzTN-Q2d7Tih73ZN_W-kkE0C1V+kDh2tcMjqrY6T=-J6fiVJw@mail.gmail.com>

With Brad King's help, the non-rendering portion of VTK was
successfully built with WebAssembly. Here is the Docker image for the
build:

  https://github.com/InsightSoftwareConsortium/itk-js/blob/master/src/Docker/itk-js-vtk/Dockerfile

We did not try OpenGL / WebGL. Note that Emscripten targets WebGL 1 /
OpenGL ES2 by default, but WebGL 2 / OpenGL ES 3 can be targeted by
passing flags.

  https://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-WebGL.html


That said, the sweet spot is itk.js-compiled-VTK-filters with vtk.js
for rendering.
 vtk.js supports WebGL 2 with a graceful fallback to WebGL 1, and
itk.js with vtk.js are easier to program and integrate with the rest
of the application.


Hope this helps,
Matt

On Wed, Jan 9, 2019 at 4:19 PM David E DeMarle <dave.demarle at kitware.com> wrote:
>
> Looks like 7.1.1 was the last version with ES2 support. 8.0 went to only ES3.
>
> Definitely talk to Matt McCormick who worked with Brad and probably JC last time.
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
>
>
> On Wed, Jan 9, 2019 at 4:16 PM Ben Boeckel via vtk-developers <vtk-developers at vtk.org> wrote:
>>
>> On Wed, Jan 09, 2019 at 15:19:29 -0500, Kyle Edwards via vtk-developers wrote:
>> > A while back, I tried buliding a minimal subset of VTK with Emscripten,
>> > the WebAssembly compiler, but it failed to compile because VTK uses
>> > features that are not in OpenGL ES2. Does anyone here have an idea of
>> > how much work would be needed to port VTK to ES2? (This is not related
>> > to vtk.js. This is an attempt to compile VTK proper from C++ to
>> > WebAssembly.)
>>
>> Brad did this at some point. What errors are you seeing? What are the
>> OpenGL-related settings (see Utilities/OpenGL/vtkOpenGLOptions.cmake)?
>>
>> --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://vtk.org/mailman/listinfo/vtk-developers
>>

From aron.helser at kitware.com  Wed Jan  9 17:34:54 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Wed, 9 Jan 2019 17:34:54 -0500
Subject: [vtk-developers] OpenVR compile error with new module system
In-Reply-To: <20190109214715.GA11685@megas.kitware.com>
References: <CAF2skS7VVanXy_qgpRpGJfnLA=JLpFhztA8NCUd6ofuz3aLJdw@mail.gmail.com>
 <20190109214715.GA11685@megas.kitware.com>
Message-ID: <CAF2skS5oZqsHxVHYGp+TfWjOvDCUWSMyytq+Oc2ueW+br136Cg@mail.gmail.com>

Yes, the vtkAvatar* should not have been listed in 'classes' - I missed
that.

The next issue I'm seeing:

   Creating library lib\vtkRenderingOpenVR-8.90d.lib and object
lib\vtkRenderingOpenVR-8.90d.exp
vtkRenderingOpenVRObjectFactory.cxx.obj : error LNK2019: unresolved
external symbol "public: static class vtkOpenGLAvatar * __cdecl
vtkOpenGLAvatar::New(void)" (?New at vtkOpenGLAvatar@@SAPEAV1 at XZ) referenced
in function "class vtkObject * __cdecl
vtkObjectFactoryCreatevtkOpenGLAvatar(void)"
(?vtkObjectFactoryCreatevtkOpenGLAvatar@@YAPEAVvtkObject@@XZ)
bin\vtkRenderingOpenVR-8.90d.dll : fatal error LNK1120: 1 unresolved
externals

I tried removing the quotes around ${vtk_object_factory_source} and header,
but no dice.

MR here:
https://gitlab.kitware.com/vtk/vtk/merge_requests/5053

Thanks!

On Wed, Jan 9, 2019 at 4:47 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Wed, Jan 09, 2019 at 16:11:54 -0500, Aron Helser wrote:
> > I found a typo in the OpenVR cmake:
> >
> > diff --git a/Rendering/OpenVR/CMakeLists.txt
> > b/Rendering/OpenVR/CMakeLists.txt
> > index a091afc3ce..810b062005 100644
> > --- a/Rendering/OpenVR/CMakeLists.txt
> > +++ b/Rendering/OpenVR/CMakeLists.txt
> > @@ -49,8 +49,8 @@ foreach (geometry_file IN LISTS geometry_files)
> >      SOURCE_OUTPUT source
> >      BINARY
> >      NUL_TERMINATE)
> > -  list(APPEND sources "${source}")
> > -  list(APPEND headers "${source}")
> > +  list(APPEND geometry_sources "${source}")
> > +  list(APPEND geometry_headers "${header}")
> >  endforeach ()
>
> Oops, indeed.
>
> > After this fix, I still get a related error:
> >
> > ninja: error:
> > 'C:/akit/vtk/src/Rendering/OpenVR/vtkAvatarHead.h', needed by
> > 'lib/vtk/hierarchy/VTK/vtkRenderingOpenVR-hierarchy.txt', missing and no
> > known rule to make it
> >
> > I'm not sure about this .txt file or what to do next?
>
> It means that a header named `vtkAvatarHead.h` is expected to be in the
> build tree?it isn't. I suspect the `vtkAvatar*` listings in `classes`
> should just be removed.
>
> Please feel free to open an MR; I don't have OpenVR here at the moment
> to test against.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/b335ac46/attachment-0001.html>

From bill.lorensen at gmail.com  Wed Jan  9 17:57:56 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 9 Jan 2019 14:57:56 -0800
Subject: [vtk-developers] Version tag and vtkversion defines for new module
Message-ID: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>

Will their be a tag and version defines for the new module system. I need
to support old and new in the VTKExamples.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190109/845da1dd/attachment.html>

From lasso at queensu.ca  Thu Jan 10 00:24:17 2019
From: lasso at queensu.ca (Andras Lasso)
Date: Thu, 10 Jan 2019 05:24:17 +0000
Subject: [vtk-developers] Version tag and vtkversion defines for new
 module
In-Reply-To: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
References: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
Message-ID: <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>

Yes, we need this. Please give us examples that show how to write our CMake and C++ files to work with both the old and new VTK module system.

Thanks!
Andras

From: vtk-developers <vtk-developers-bounces at vtk.org> On Behalf Of Bill Lorensen
Sent: Wednesday, January 9, 2019 5:58 PM
To: VTK Developers <vtk-developers at vtk.org>
Subject: [vtk-developers] Version tag and vtkversion defines for new module

Will their be a tag and version defines for the new module system. I need to support old and new in the VTKExamples.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/f0228738/attachment.html>

From ben.boeckel at kitware.com  Thu Jan 10 09:05:05 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 09:05:05 -0500
Subject: [vtk-developers] Version tag and vtkversion defines for new
 module
In-Reply-To: <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
References: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
 <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <20190110140505.GC4758@megas.kitware.com>

On Thu, Jan 10, 2019 at 05:24:17 +0000, Andras Lasso wrote:
> Yes, we need this. Please give us examples that show how to write our
> CMake and C++ files to work with both the old and new VTK module
> system.

I have some patches for WikiExamples locally, but have been focusing on
the dashboards first.

For supporting both, something like this pattern is what I was doing:

    find_package(VTK)
    if (VTK_VERSION VERSION_LESS "8.90")
      # old system
      include(${VTK_USE_FILE})
      # modules are linked via `vtkCommonCore`
      # VTK_DEFINITIONS has autoinit information
    else ()
      # modules are linked via `VTK::CommonCore`
      # vtk_module_autoinit is needed
    endif ()

WikiExamples also tries to support VTK5, so it has a bit more logic to
go in there as well.

--Ben

From bill.lorensen at gmail.com  Thu Jan 10 11:32:24 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 08:32:24 -0800
Subject: [vtk-developers] Version tag and vtkversion defines for new
 module
In-Reply-To: <20190110140505.GC4758@megas.kitware.com>
References: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
 <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <20190110140505.GC4758@megas.kitware.com>
Message-ID: <CADZJ4hN=4c0o2MQTDg_uLbGTOgnhBzKrDhfG7e2nVXu0jz6yvg@mail.gmail.com>

We can drop VTK5 support.

Thanks

Bill

On Thu, Jan 10, 2019, 6:05 AM Ben Boeckel <ben.boeckel at kitware.com wrote:

> On Thu, Jan 10, 2019 at 05:24:17 +0000, Andras Lasso wrote:
> > Yes, we need this. Please give us examples that show how to write our
> > CMake and C++ files to work with both the old and new VTK module
> > system.
>
> I have some patches for WikiExamples locally, but have been focusing on
> the dashboards first.
>
> For supporting both, something like this pattern is what I was doing:
>
>     find_package(VTK)
>     if (VTK_VERSION VERSION_LESS "8.90")
>       # old system
>       include(${VTK_USE_FILE})
>       # modules are linked via `vtkCommonCore`
>       # VTK_DEFINITIONS has autoinit information
>     else ()
>       # modules are linked via `VTK::CommonCore`
>       # vtk_module_autoinit is needed
>     endif ()
>
> WikiExamples also tries to support VTK5, so it has a bit more logic to
> go in there as well.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/c27d8122/attachment.html>

From aron.helser at kitware.com  Thu Jan 10 12:18:37 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Thu, 10 Jan 2019 12:18:37 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <20190109200640.GA24952@megas.kitware.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
Message-ID: <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>

With a very similar cmake file, I'm seeing the error:

CMake Error at CMakeLists.txt:6 (include):
include called with wrong number of arguments. include() only takes one
file.


I pointed VTK_Dir at ".....vtk/build/lib/cmake/vtk-8.90" , like you
suggested. My VTK build does have OpenVR enabled, on windows, so I have to
set OpenVR_INCLUDE_DIR and OpenVR_LIBRARY.


If I change to:


include("${VTK_USE_FILE}")


It warns that no file was provided, then during compile it can't find VTK
headers.


The find_package(VTK REQUIRED) is going wrong?'


What am I doing wrong?

Thanks,

Aron

On Wed, Jan 9, 2019 at 3:06 PM Ben Boeckel via vtk-developers <
vtk-developers at vtk.org> wrote:

> On Wed, Jan 09, 2019 at 11:44:01 -0800, Bill Lorensen wrote:
> > TYhis cmake file:
> > cmake_minimum_required(VERSION 2.8)
> >
> > PROJECT(ReadOBJ)
> >
> > find_package(VTK REQUIRED)
> > include(${VTK_USE_FILE})
> >
> > add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> >
> > target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
> >
> > I specify the VTK_DIR to point at a new module VTK build. I'm using
> > cmake version 3.10.3
>
> The vtk-config.cmake file is in the `lib/cmake/vtk-*` directory of the
> build tree, not the top-level. This mirrors the install tree and also
> keeps the code between the two very similar (instead of having to differ
> on relative paths to other generated CMake files).
>
> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/e082f196/attachment.html>

From aron.helser at kitware.com  Thu Jan 10 12:24:07 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Thu, 10 Jan 2019 12:24:07 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
Message-ID: <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>

Sorry, I should have started with the original problem. I started with this
file:

cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
PROJECT (mineview)
find_package(VTK REQUIRED)
vtk_module_config(VTK
  vtkCommonCore
  vtkCommonDataModel
  vtkFiltersGeneral
  vtkIOFFMPEG
  vtkIOImage
  vtkIOXML
  vtkInteractionStyle
  vtkRenderingOpenGL2
  vtkRenderingOpenVR
)
include(${VTK_USE_FILE})

add_executable(mineview MACOSX_BUNDLE mineview.cxx Lobby.cxx View.cxx
AudioHandler.cxx)
target_link_libraries(mineview ${VTK_LIBRARIES} Xaudio2.lib opengl32
winmm.lib)

but "vtk_module_config" doesn't exist anymore, right? So I tried to change
to this:
find_package(VTK
  COMPONENTS
  vtkCommonCore
 ...

but then it complains:

CMake Warning at CMakeLists.txt:5 (find_package):
Found package configuration file:

C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake

but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
FOUND. Reason given by package:

Could not find the VTK package with the following required components:
vtkCommonCore.


Thus I am confused. :)
Hope those breadcrumbs help?
Thanks,
Aron


On Thu, Jan 10, 2019 at 12:18 PM Aron Helser <aron.helser at kitware.com>
wrote:

> With a very similar cmake file, I'm seeing the error:
>
> CMake Error at CMakeLists.txt:6 (include):
> include called with wrong number of arguments. include() only takes one
> file.
>
>
> I pointed VTK_Dir at ".....vtk/build/lib/cmake/vtk-8.90" , like you
> suggested. My VTK build does have OpenVR enabled, on windows, so I have to
> set OpenVR_INCLUDE_DIR and OpenVR_LIBRARY.
>
>
> If I change to:
>
>
> include("${VTK_USE_FILE}")
>
>
> It warns that no file was provided, then during compile it can't find VTK
> headers.
>
>
> The find_package(VTK REQUIRED) is going wrong?'
>
>
> What am I doing wrong?
>
> Thanks,
>
> Aron
>
> On Wed, Jan 9, 2019 at 3:06 PM Ben Boeckel via vtk-developers <
> vtk-developers at vtk.org> wrote:
>
>> On Wed, Jan 09, 2019 at 11:44:01 -0800, Bill Lorensen wrote:
>> > TYhis cmake file:
>> > cmake_minimum_required(VERSION 2.8)
>> >
>> > PROJECT(ReadOBJ)
>> >
>> > find_package(VTK REQUIRED)
>> > include(${VTK_USE_FILE})
>> >
>> > add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
>> >
>> > target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
>> >
>> > I specify the VTK_DIR to point at a new module VTK build. I'm using
>> > cmake version 3.10.3
>>
>> The vtk-config.cmake file is in the `lib/cmake/vtk-*` directory of the
>> build tree, not the top-level. This mirrors the install tree and also
>> keeps the code between the two very similar (instead of having to differ
>> on relative paths to other generated CMake files).
>>
>> --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://vtk.org/mailman/listinfo/vtk-developers
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/a1d76c89/attachment.html>

From ben.boeckel at kitware.com  Thu Jan 10 12:29:32 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 12:29:32 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
Message-ID: <20190110172932.GA30439@megas.kitware.com>

On Thu, Jan 10, 2019 at 12:18:37 -0500, Aron Helser wrote:
> include("${VTK_USE_FILE}")

VTK_USE_FILE isn't provided anymore since it isn't necessary.
`find_package(VTK)` is all that is necessary.

--Ben

From ben.boeckel at kitware.com  Thu Jan 10 13:37:23 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 13:37:23 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
Message-ID: <20190110183723.GA22349@megas.kitware.com>

On Thu, Jan 10, 2019 at 12:24:07 -0500, Aron Helser wrote:
> Sorry, I should have started with the original problem. I started with this
> file:
> 
> cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
> PROJECT (mineview)
> find_package(VTK REQUIRED)
> vtk_module_config(VTK
>   vtkCommonCore
>   vtkCommonDataModel
>   vtkFiltersGeneral
>   vtkIOFFMPEG
>   vtkIOImage
>   vtkIOXML
>   vtkInteractionStyle
>   vtkRenderingOpenGL2
>   vtkRenderingOpenVR
> )
> include(${VTK_USE_FILE})
> 
> add_executable(mineview MACOSX_BUNDLE mineview.cxx Lobby.cxx View.cxx
> AudioHandler.cxx)
> target_link_libraries(mineview ${VTK_LIBRARIES} Xaudio2.lib opengl32
> winmm.lib)
> 
> but "vtk_module_config" doesn't exist anymore, right? So I tried to change
> to this:
> find_package(VTK
>   COMPONENTS
>   vtkCommonCore
>  ...
> 
> but then it complains:
> 
> CMake Warning at CMakeLists.txt:5 (find_package):
> Found package configuration file:
> 
> C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake
> 
> but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
> FOUND. Reason given by package:
> 
> Could not find the VTK package with the following required components:
> vtkCommonCore.
> 
> 
> Thus I am confused. :)
> Hope those breadcrumbs help?

COMPONENTS are now `CommonCore` and `FiltersGeneral` since they end up
like `VTK::CommonCore`. I suppose the components list could be
preprocessed to detect a leading `vtk` and remove it (warning that that
name is deprecated).

--Ben

From bill.lorensen at gmail.com  Thu Jan 10 14:00:33 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 11:00:33 -0800
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <20190110183723.GA22349@megas.kitware.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
Message-ID: <CADZJ4hOmXVy16e+JpDG9mTxJz6901V35FVyR6r=mvN_xwnDZ-g@mail.gmail.com>

I'm curious why the component names were changed.

On Thu, Jan 10, 2019, 10:37 AM Ben Boeckel <ben.boeckel at kitware.com wrote:

> On Thu, Jan 10, 2019 at 12:24:07 -0500, Aron Helser wrote:
> > Sorry, I should have started with the original problem. I started with
> this
> > file:
> >
> > cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
> > PROJECT (mineview)
> > find_package(VTK REQUIRED)
> > vtk_module_config(VTK
> >   vtkCommonCore
> >   vtkCommonDataModel
> >   vtkFiltersGeneral
> >   vtkIOFFMPEG
> >   vtkIOImage
> >   vtkIOXML
> >   vtkInteractionStyle
> >   vtkRenderingOpenGL2
> >   vtkRenderingOpenVR
> > )
> > include(${VTK_USE_FILE})
> >
> > add_executable(mineview MACOSX_BUNDLE mineview.cxx Lobby.cxx View.cxx
> > AudioHandler.cxx)
> > target_link_libraries(mineview ${VTK_LIBRARIES} Xaudio2.lib opengl32
> > winmm.lib)
> >
> > but "vtk_module_config" doesn't exist anymore, right? So I tried to
> change
> > to this:
> > find_package(VTK
> >   COMPONENTS
> >   vtkCommonCore
> >  ...
> >
> > but then it complains:
> >
> > CMake Warning at CMakeLists.txt:5 (find_package):
> > Found package configuration file:
> >
> > C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake
> >
> > but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
> > FOUND. Reason given by package:
> >
> > Could not find the VTK package with the following required components:
> > vtkCommonCore.
> >
> >
> > Thus I am confused. :)
> > Hope those breadcrumbs help?
>
> COMPONENTS are now `CommonCore` and `FiltersGeneral` since they end up
> like `VTK::CommonCore`. I suppose the components list could be
> preprocessed to detect a leading `vtk` and remove it (warning that that
> name is deprecated).
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/d53a0789/attachment-0001.html>

From aron.helser at kitware.com  Thu Jan 10 14:01:59 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Thu, 10 Jan 2019 14:01:59 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <20190110183723.GA22349@megas.kitware.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
Message-ID: <CAF2skS6ttBoQD24i=WtvSBU+ADGnS1Wx_bwnj_sNL+G4cVLgwQ@mail.gmail.com>

Yep, just figured that out, thanks!

 Unfortunately, I'm still having a problem just with IOFFMPEG - I need it
for 'vtkFFMPEGVideoSource.h', but mineview cmake reports:

> -- Could NOT find FFMPEG (missing: FFMPEG_INCLUDE_DIRS FFMPEG_LIBRARIES
> avformat avcodec avutil swscale) (Required is at least version "4.0")
> -- Could not find the VTK package due to a missing dependency: FFMPEG
> CMake Warning at CMakeLists.txt:5 (find_package):
>   Found package configuration file:
>     C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake
>   but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
>   FOUND.  Reason given by package:
>   Could not find the VTK package with the following required components:
>   IOFFMPEG.


I'm setting FFMPEG_ROOT to compile vtk, so then if I set it for my app, I
get a warning:

CMake Warning (dev) at
> C:/akit/vtk/build/lib/cmake/vtk-8.90/VTK-vtk-module-find-packages.cmake:279
> (find_package):
> Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
> Run "cmake --help-policy CMP0074" for policy details. Use the cmake_policy
> command to set the policy and suppress this warning. CMake variable
> FFMPEG_ROOT is set to: c:/akit/mineview/src/ffmpeg For compatibility,
> CMake is ignoring the variable.
> Call Stack (most recent call first):
> C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake:62 (include)
> CMakeLists.txt:5 (find_package)


But my app compiles! So I'm not sure about the warning?

On Thu, Jan 10, 2019 at 1:37 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Thu, Jan 10, 2019 at 12:24:07 -0500, Aron Helser wrote:
> > Sorry, I should have started with the original problem. I started with
> this
> > file:
> >
> > cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
> > PROJECT (mineview)
> > find_package(VTK REQUIRED)
> > vtk_module_config(VTK
> >   vtkCommonCore
> >   vtkCommonDataModel
> >   vtkFiltersGeneral
> >   vtkIOFFMPEG
> >   vtkIOImage
> >   vtkIOXML
> >   vtkInteractionStyle
> >   vtkRenderingOpenGL2
> >   vtkRenderingOpenVR
> > )
> > include(${VTK_USE_FILE})
> >
> > add_executable(mineview MACOSX_BUNDLE mineview.cxx Lobby.cxx View.cxx
> > AudioHandler.cxx)
> > target_link_libraries(mineview ${VTK_LIBRARIES} Xaudio2.lib opengl32
> > winmm.lib)
> >
> > but "vtk_module_config" doesn't exist anymore, right? So I tried to
> change
> > to this:
> > find_package(VTK
> >   COMPONENTS
> >   vtkCommonCore
> >  ...
> >
> > but then it complains:
> >
> > CMake Warning at CMakeLists.txt:5 (find_package):
> > Found package configuration file:
> >
> > C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake
> >
> > but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
> > FOUND. Reason given by package:
> >
> > Could not find the VTK package with the following required components:
> > vtkCommonCore.
> >
> >
> > Thus I am confused. :)
> > Hope those breadcrumbs help?
>
> COMPONENTS are now `CommonCore` and `FiltersGeneral` since they end up
> like `VTK::CommonCore`. I suppose the components list could be
> preprocessed to detect a leading `vtk` and remove it (warning that that
> name is deprecated).
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/1a11dc32/attachment.html>

From bill.lorensen at gmail.com  Thu Jan 10 14:13:53 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 11:13:53 -0800
Subject: [vtk-developers] Version tag and vtkversion defines for new
 module
In-Reply-To: <20190110140505.GC4758@megas.kitware.com>
References: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
 <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <20190110140505.GC4758@megas.kitware.com>
Message-ID: <CADZJ4hOF1ZXFtJpRRt3_XyVSdqiW5Mnc_4z2EBjF2Kt6C4VPjw@mail.gmail.com>

When I use
cmake_minimum_required(VERSION 3.0)


On Thu, Jan 10, 2019 at 6:05 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:
>
> On Thu, Jan 10, 2019 at 05:24:17 +0000, Andras Lasso wrote:
> > Yes, we need this. Please give us examples that show how to write our
> > CMake and C++ files to work with both the old and new VTK module
> > system.
>
> I have some patches for WikiExamples locally, but have been focusing on
> the dashboards first.
>
> For supporting both, something like this pattern is what I was doing:
>
>     find_package(VTK)
>     if (VTK_VERSION VERSION_LESS "8.90")
>       # old system
>       include(${VTK_USE_FILE})
>       # modules are linked via `vtkCommonCore`
>       # VTK_DEFINITIONS has autoinit information
>     else ()
>       # modules are linked via `VTK::CommonCore`
>       # vtk_module_autoinit is needed
>     endif ()
>
> WikiExamples also tries to support VTK5, so it has a bit more logic to
> go in there as well.
>
> --Ben



-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Thu Jan 10 14:44:33 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 14:44:33 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CADZJ4hOmXVy16e+JpDG9mTxJz6901V35FVyR6r=mvN_xwnDZ-g@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
 <CADZJ4hOmXVy16e+JpDG9mTxJz6901V35FVyR6r=mvN_xwnDZ-g@mail.gmail.com>
Message-ID: <20190110194433.GA29798@megas.kitware.com>

On Thu, Jan 10, 2019 at 11:00:33 -0800, Bill Lorensen wrote:
> I'm curious why the component names were changed.

Short answer:

CMake intricacies and simpler code on the module system's side.

That said, the translation code is possible to do (though I don't think
I'll get to it right away; feel free to make an MR and I can review).

Long answer:

The idea was to have the name used to link in the build and install tree
be exactly the same. When exporting with a namespace, CMake does
`<namespace>::<target>` without support for renaming `<target>`. The
module system helps to write out the `find_package(dependency)` calls
based on the requested components for which it needs to know their
names. The old component names could have been preserved, but that would
have resulted in targets like `VTK::vtkCommonCore` which I originally
kept, but discussions with others said that `VTK::CommonCore` was
preferred.

--Ben

From ben.boeckel at kitware.com  Thu Jan 10 14:50:27 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 14:50:27 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <CAF2skS6ttBoQD24i=WtvSBU+ADGnS1Wx_bwnj_sNL+G4cVLgwQ@mail.gmail.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
 <CAF2skS6ttBoQD24i=WtvSBU+ADGnS1Wx_bwnj_sNL+G4cVLgwQ@mail.gmail.com>
Message-ID: <20190110195027.GB29798@megas.kitware.com>

On Thu, Jan 10, 2019 at 14:01:59 -0500, Aron Helser wrote:
> Yep, just figured that out, thanks!
> 
>  Unfortunately, I'm still having a problem just with IOFFMPEG - I need it
> for 'vtkFFMPEGVideoSource.h', but mineview cmake reports:
> 
> > -- Could NOT find FFMPEG (missing: FFMPEG_INCLUDE_DIRS FFMPEG_LIBRARIES
> > avformat avcodec avutil swscale) (Required is at least version "4.0")
> > -- Could not find the VTK package due to a missing dependency: FFMPEG
> > CMake Warning at CMakeLists.txt:5 (find_package):
> >   Found package configuration file:
> >     C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake
> >   but it set VTK_FOUND to FALSE so package "VTK" is considered to be NOT
> >   FOUND.  Reason given by package:
> >   Could not find the VTK package with the following required components:
> >   IOFFMPEG.

If you look in `CMake/vtkInstallCMakePackage.cmake`, there is a TODO
item to build up a list of prefix paths to hard-code into the build
tree. This is what would help. The issue is that the list of prefixes to
add is not immediately trivial to figure out since the list of packages
and how to make a prefix from them are quite expansive.

THe first thing that is needed is the list of packages that were found
during the build (`vtk_module_find_package` serves as the entry to the
package forwarding logic, so modifying it to register what packages are
wanted globally could help). From there, for each found package,
determining a prefix based on its cache variables is necessary.

Alternatively, `vtk_module_find_package` could take additional arguments
to figure out a prefix and make that list of prefixes what is available.
That might be more useful in the long run.

> I'm setting FFMPEG_ROOT to compile vtk, so then if I set it for my app, I
> get a warning:
> 
> CMake Warning (dev) at
> > C:/akit/vtk/build/lib/cmake/vtk-8.90/VTK-vtk-module-find-packages.cmake:279
> > (find_package):
> > Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
> > Run "cmake --help-policy CMP0074" for policy details. Use the cmake_policy
> > command to set the policy and suppress this warning. CMake variable
> > FFMPEG_ROOT is set to: c:/akit/mineview/src/ffmpeg For compatibility,
> > CMake is ignoring the variable.
> > Call Stack (most recent call first):
> > C:/akit/vtk/build/lib/cmake/vtk-8.90/vtk-config.cmake:62 (include)
> > CMakeLists.txt:5 (find_package)
> 
> 
> But my app compiles! So I'm not sure about the warning?

It's a policy warning. We could set it in `vtk-config.cmake` since the
modules VTK is using should be policy-clean here. A policy scope should
be used though.

--Ben

From ben.boeckel at kitware.com  Thu Jan 10 15:05:43 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 15:05:43 -0500
Subject: [vtk-developers] Version tag and vtkversion defines for new
 module
In-Reply-To: <CADZJ4hOF1ZXFtJpRRt3_XyVSdqiW5Mnc_4z2EBjF2Kt6C4VPjw@mail.gmail.com>
References: <CADZJ4hMgxQumQibtXXKqLex+g1Y22qGyEfDBSqPXkLdptGQgXw@mail.gmail.com>
 <YTOPR0101MB1292743221AA0E6D42AA8EA6D8840@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <20190110140505.GC4758@megas.kitware.com>
 <CADZJ4hOF1ZXFtJpRRt3_XyVSdqiW5Mnc_4z2EBjF2Kt6C4VPjw@mail.gmail.com>
Message-ID: <20190110200543.GA23899@megas.kitware.com>

On Thu, Jan 10, 2019 at 11:13:53 -0800, Bill Lorensen wrote:
> When I use
> cmake_minimum_required(VERSION 3.0)

I'm assuming there was supposed to be more here, but CMake 3.8 is
required to use the new module system. Are there policy warnings when
doing this? If so, we should probably just set 3.8 as the policy scope
in vtk-config.cmake.

--Ben

From will.schroeder at kitware.com  Thu Jan 10 15:42:19 2019
From: will.schroeder at kitware.com (Will Schroeder)
Date: Thu, 10 Jan 2019 15:42:19 -0500
Subject: [vtk-developers] FYI vtkPolyData::GetCellEdgeNeighbors()
Message-ID: <CAEiDrtX-tpsCiSDapGLFWxhjchiHWQdcjf53+5n_iL3c2tF0vw@mail.gmail.com>

I wanted to preserve a discussion that Joachim recently initiated.
Basically he encountered unexpected behavior when invoking
GetCellEdgeNeighbors() (see attached figure from Joachim). Basically,
triangle C is returned as a neighbor to triangle A edge(0,1).

Note that the documentation of vtkDataSet::GetCellNeighbors() and the
specialized method vtkPolyData::GetCellEdgeNeighbors() reads something like:

"Topological inquiry to get all cells using list of points exclusive of the
cell specified (e.g., cellId). Note that the list consists of only cells
that use ALL the points provided."

So it produces the results as documented, but in cases where you have
concave, or self-intersecting (non-compatible meshes) cells you may see
unexpected results.

Other notes:
+ Similar cases can be found for face neighbors using GetCellNeighbors()
+ The other concept that needs to be brought out I think we can call
"symmetry". Given two cells A and B, with E an edge of A. If the neighbor
N(A,E) = B, and N(B,E) = A then the neighbor operation is symmetric.
However if the cell B has no edge E, then the symmetry property fails. In
other words, the intersection of A?B must contain E (I'm not sure symmetry
is the right term, we have to think about this.) I think we can show that
for convex, non-intersecting (i.e., compatible) meshes, the neighbor
operation is symmetric.

There are a couple of approaches to addressing this: adding new methods,
changing the behavior of the old one, modifying filters like feature edges
to be symmetry aware (it would be a fun addition) etc. Longer term if VTK
is to be used more for explicit geometric modelling (as compared to
volumetric/implicit modeling) then better data structures and API are
probably needed.

AFAIK this is in the mulling stage. Of course any feedback and comments are
encouraged.

Best,
Will

-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/a91124cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edgeneighbors.png
Type: image/png
Size: 101592 bytes
Desc: not available
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/a91124cf/attachment-0001.png>

From ben.boeckel at kitware.com  Thu Jan 10 17:07:12 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 17:07:12 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190108231154.GA29838@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
Message-ID: <20190110220712.GA21739@megas.kitware.com>

On Tue, Jan 08, 2019 at 18:11:54 -0500, Ben Boeckel wrote:
> Current state of test failures:
> 
>   - taanab and adora: CMake is warning about the inability to make
>     fully correct rpath variables for targets. There may be a way to fix
>     this, but it may be up to doing a suppression as well.

Once things have settled down a bit, I'll look into this more.

>   - duma: it should be using OSMesa, but is not.

How to get this working properly is under discussion:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5044

>   - example tests: Examples aren't downloading example data properly.

This has been fixed.

>   - various machines: since freetype has been updated, it seems that
>     some new baselines will need to be added. I'll do that as well, but
>     feel free to grab some if you want.

New baselines have been added.

>   - mun: static build failure with jsoncpp symbols. Will look into this
>     tomorrow.

Fixed.

>   - mun: shared+kits Python tests are failing. I suspect a missing PATH
>     entry or the like. Will investgate tomorrow.

Still not working. Needs more investigation.

The state of testing is as follows:

  - Tests failing on multiple machines. These seem worth looking into.
      * VTK::IOGDALCxx-TestGDALRasterReader
            scalar array count mismatch
      * VTK::RenderingExternalCxx-TestGLUTRenderWindow
            fails to get an OpenGL 3.2 context on some machines
      * VTK::RenderingFreeTypeFontConfigCxx-TestSystemFontRendering
            trey isn't rendering the Times fonts as italic
      * VTK::IOExportPDFCxx-TestPDFTransformedText
            Not really sure what's going on here. There's no test image
            for comparison.
      * VTK::IOParallelLSDynaCxx-MPI-PLSDynaReader
            Looks to be a scaling issue, but the geometry looks OK.
      * VTK::IOParallelXMLPython-MPI-testParallelXMLWriters
            Assertion about the number of triangles failing.
      * VTK::RenderingMatplotlibCxx-TestGL2PSMathTextOutput-VerifyRasterizedPNG
            Image size mismatch.
      * VTK::RenderingMatplotlibCxx-TestRenderString
            Image size mismatch.
      * VTK::IOVPICCxx-TestVPICReader
            Failing on Windows due to it expecting `\` path separators
            but being passed `/` path separators. I tried to fix it, but
            it wasn't sufficient. Needs more debugging.
      * VTK::RenderingCoreCxx-TestFollowerPicking
            Currently disabled on taanab (it was previously) due to
            error messages:
                vtkInteractorStyleJoystickCamera (0x1e0e030): Timer start failed
      * Example tests on Windows
            Needs prefixes filled out as mentioned here:
                https://public.kitware.com/pipermail/vtk-developers/2019-January/036703.html
  - The static+python builder has had Python disabled for now
        https://gitlab.kitware.com/vtk/vtk/issues/17478
  - bigmac has a number of tests which end up with a pixel or two off
    for the test image size compared to the baselines. Not sure why this
    is. Most, but not all, of them are volume rendering tests.
  - adora is still failing to do XQueryExtension which seems?odd. Still
    need to look into it more.

All third party warnings have been suppressed for now (though some may
slip through yet). I'll deal with those in the future.

--Ben

From ben.boeckel at kitware.com  Thu Jan 10 17:08:06 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 17:08:06 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <20190110195027.GB29798@megas.kitware.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
 <CAF2skS6ttBoQD24i=WtvSBU+ADGnS1Wx_bwnj_sNL+G4cVLgwQ@mail.gmail.com>
 <20190110195027.GB29798@megas.kitware.com>
Message-ID: <20190110220806.GB21739@megas.kitware.com>

On Thu, Jan 10, 2019 at 14:50:27 -0500, Ben Boeckel wrote:
> On Thu, Jan 10, 2019 at 14:01:59 -0500, Aron Helser wrote:
> > But my app compiles! So I'm not sure about the warning?
> 
> It's a policy warning. We could set it in `vtk-config.cmake` since the
> modules VTK is using should be policy-clean here. A policy scope should
> be used though.

This and the component name compatibility have been added here:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5056

--Ben

From bill.lorensen at gmail.com  Thu Jan 10 17:08:28 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 14:08:28 -0800
Subject: [vtk-developers] Missing Includes with new module system
Message-ID: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>

I have a simple program that fails to find the vtk include files:
Here is the CMakeLists.txt fiile:
cmake_minimum_required(VERSION 3.8)

PROJECT(ReadOBJ)
Find_package(VTK)
if (VTK_VERSION VERSION_LESS "8.90")
  # old system
  include(${VTK_USE_FILE})
  # modules are linked via `vtkCommonCore`
  # VTK_DEFINITIONS has autoinit information
else ()
  # modules are linked via `VTK::CommonCore`
  # vtk_module_autoinit is needed
endif ()

add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
target_link_libraries(ReadOBJ ${VTK_LIBRARIES})

The source file is here:
https://raw.githubusercontent.com/lorensen/VTKExamples/master/src/Cxx/IO/ReadOBJ.cxx

I get the error:
[build] cmake -DVTK_DIR:PATH=/Users/lorensen/ProjectsGIT/VTKNewModules-clang/lib/cmake/vtk-8.90/
..
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ReadOBJ/build
[build] make
[ 50%] Building CXX object CMakeFiles/ReadOBJ.dir/ReadOBJ.cxx.o
/tmp/ReadOBJ/ReadOBJ.cxx:1:10: fatal error: 'vtkOBJReader.h' file not found
#include <vtkOBJReader.h>
         ^~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/ReadOBJ.dir/ReadOBJ.cxx.o] Error 1
make[1]: *** [CMakeFiles/ReadOBJ.dir/all] Error 2
make: *** [all] Error 2
[build] cmake --version
cmake version 3.10.3


-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Thu Jan 10 18:07:19 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 10 Jan 2019 18:07:19 -0500
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
Message-ID: <20190110230719.GA7191@megas.kitware.com>

On Thu, Jan 10, 2019 at 14:08:28 -0800, Bill Lorensen wrote:
> I have a simple program that fails to find the vtk include files:
> Here is the CMakeLists.txt fiile:
> cmake_minimum_required(VERSION 3.8)
> 
> PROJECT(ReadOBJ)
> Find_package(VTK)
> if (VTK_VERSION VERSION_LESS "8.90")
>   # old system
>   include(${VTK_USE_FILE})
>   # modules are linked via `vtkCommonCore`
>   # VTK_DEFINITIONS has autoinit information
> else ()
>   # modules are linked via `VTK::CommonCore`
>   # vtk_module_autoinit is needed
> endif ()
> 
> add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> target_link_libraries(ReadOBJ ${VTK_LIBRARIES})

Hmm. What is `VTK_LIBRARIES` set to?

--Ben

From bill.lorensen at gmail.com  Thu Jan 10 18:27:00 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 15:27:00 -0800
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <20190110230719.GA7191@megas.kitware.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
Message-ID: <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>

VTK_LIBRARIES is empty.



On Jan 10, 2019 3:07 PM, "Ben Boeckel" <ben.boeckel at kitware.com> wrote:

On Thu, Jan 10, 2019 at 14:08:28 -0800, Bill Lorensen wrote:
> I have a simple program that fails to find the vtk include files:
> Here is the CMakeLists.txt fiile:
> cmake_minimum_required(VERSION 3.8)
>
> PROJECT(ReadOBJ)
> Find_package(VTK)
> if (VTK_VERSION VERSION_LESS "8.90")
>   # old system
>   include(${VTK_USE_FILE})
>   # modules are linked via `vtkCommonCore`
>   # VTK_DEFINITIONS has autoinit information
> else ()
>   # modules are linked via `VTK::CommonCore`
>   # vtk_module_autoinit is needed
> endif ()
>
> add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> target_link_libraries(ReadOBJ ${VTK_LIBRARIES})

Hmm. What is `VTK_LIBRARIES` set to?


--Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190110/ff10378a/attachment.html>

From bill.lorensen at gmail.com  Thu Jan 10 19:06:38 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 16:06:38 -0800
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
Message-ID: <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>

I'm not specifying any components. If add the required components it works.
Before, I did not have to specify components... This is troublesome.

Bill

On Thu, Jan 10, 2019 at 3:27 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> VTK_LIBRARIES is empty.
>
>
>
> On Jan 10, 2019 3:07 PM, "Ben Boeckel" <ben.boeckel at kitware.com> wrote:
>
> On Thu, Jan 10, 2019 at 14:08:28 -0800, Bill Lorensen wrote:
> > I have a simple program that fails to find the vtk include files:
> > Here is the CMakeLists.txt fiile:
> > cmake_minimum_required(VERSION 3.8)
> >
> > PROJECT(ReadOBJ)
> > Find_package(VTK)
> > if (VTK_VERSION VERSION_LESS "8.90")
> >   # old system
> >   include(${VTK_USE_FILE})
> >   # modules are linked via `vtkCommonCore`
> >   # VTK_DEFINITIONS has autoinit information
> > else ()
> >   # modules are linked via `VTK::CommonCore`
> >   # vtk_module_autoinit is needed
> > endif ()
> >
> > add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> > target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
>
> Hmm. What is `VTK_LIBRARIES` set to?
>
>
> --Ben
>
>


-- 
Unpaid intern in BillsParadise at noware dot com

From bill.lorensen at gmail.com  Thu Jan 10 19:10:30 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 16:10:30 -0800
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
 <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
Message-ID: <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>

I have over 1000 C++ examples. The cmakelists.txt file on the web page
for each example is generated from a template file. So I can fix it
for all web but it is ugly...

Here is the working, general cmakelists.txt file:
cmake_minimum_required(VERSION 3.8)

PROJECT(ReadOBJ)
Find_package(VTK CONFIG)
if (VTK_VERSION VERSION_LESS "8.90")
  # old system
  Find_package(VTK REQUIRED)
  include(${VTK_USE_FILE})
  # modules are linked via `vtkCommonCore`
  # VTK_DEFINITIONS has autoinit information
else ()
  # modules are linked via `VTK::CommonCore`
  # vtk_module_autoinit is needed
  Find_package(VTK COMPONENTS
  ChartsCore
  CommonColor
  CommonComputationalGeometry
  CommonSystem
  FiltersExtraction
  FiltersFlowPaths
  FiltersGeneric
  FiltersGeometry
  FiltersHybrid
  FiltersModeling
  # FiltersParallelStatistics #  Optional
  FiltersPoints
  FiltersProgrammable
  FiltersTexture
  FiltersVerdict
  GeovisCore
  IOExodus
  IOExport
  # IOFFMPEG # Optional
  IOImport
  IOInfovis
  # IOMySQL # Optional
  IOPLY
  IOParallel
  IOParallelXML
  ImagingColor
  ImagingFourier
  ImagingHybrid
  ImagingMath
  ImagingMorphological
  ImagingSources
  ImagingStatistics
  ImagingStencil
  # InfovisBoostGraphAlgorithms # Optional
  InfovisLayout
  InteractionImage
  RenderingAnnotation
  RenderingContextOpenGL2
  RenderingImage
  RenderingLOD
  RenderingLabel
  RenderingOpenGL2
  RenderingVolumeOpenGL2
  TestingGenericBridge
  TestingRendering
  ViewsContext2D
  ViewsInfovis
)
endif ()
add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
target_link_libraries(ReadOBJ ${VTK_LIBRARIES})

On Thu, Jan 10, 2019 at 4:06 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> I'm not specifying any components. If add the required components it works.
> Before, I did not have to specify components... This is troublesome.
>
> Bill
>
> On Thu, Jan 10, 2019 at 3:27 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
> >
> > VTK_LIBRARIES is empty.
> >
> >
> >
> > On Jan 10, 2019 3:07 PM, "Ben Boeckel" <ben.boeckel at kitware.com> wrote:
> >
> > On Thu, Jan 10, 2019 at 14:08:28 -0800, Bill Lorensen wrote:
> > > I have a simple program that fails to find the vtk include files:
> > > Here is the CMakeLists.txt fiile:
> > > cmake_minimum_required(VERSION 3.8)
> > >
> > > PROJECT(ReadOBJ)
> > > Find_package(VTK)
> > > if (VTK_VERSION VERSION_LESS "8.90")
> > >   # old system
> > >   include(${VTK_USE_FILE})
> > >   # modules are linked via `vtkCommonCore`
> > >   # VTK_DEFINITIONS has autoinit information
> > > else ()
> > >   # modules are linked via `VTK::CommonCore`
> > >   # vtk_module_autoinit is needed
> > > endif ()
> > >
> > > add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> > > target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
> >
> > Hmm. What is `VTK_LIBRARIES` set to?
> >
> >
> > --Ben
> >
> >
>
>
> --
> Unpaid intern in BillsParadise at noware dot com



-- 
Unpaid intern in BillsParadise at noware dot com

From bill.lorensen at gmail.com  Thu Jan 10 19:12:26 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 10 Jan 2019 16:12:26 -0800
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
 <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
 <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>
Message-ID: <CADZJ4hOtjZnmt8w75_14dzrOVEa=ZvWFh7Vicy5hMvTv3iPttg@mail.gmail.com>

Is there a VTK cmake variable that lists all components in a particular build?

On Thu, Jan 10, 2019 at 4:10 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> I have over 1000 C++ examples. The cmakelists.txt file on the web page
> for each example is generated from a template file. So I can fix it
> for all web but it is ugly...
>
> Here is the working, general cmakelists.txt file:
> cmake_minimum_required(VERSION 3.8)
>
> PROJECT(ReadOBJ)
> Find_package(VTK CONFIG)
> if (VTK_VERSION VERSION_LESS "8.90")
>   # old system
>   Find_package(VTK REQUIRED)
>   include(${VTK_USE_FILE})
>   # modules are linked via `vtkCommonCore`
>   # VTK_DEFINITIONS has autoinit information
> else ()
>   # modules are linked via `VTK::CommonCore`
>   # vtk_module_autoinit is needed
>   Find_package(VTK COMPONENTS
>   ChartsCore
>   CommonColor
>   CommonComputationalGeometry
>   CommonSystem
>   FiltersExtraction
>   FiltersFlowPaths
>   FiltersGeneric
>   FiltersGeometry
>   FiltersHybrid
>   FiltersModeling
>   # FiltersParallelStatistics #  Optional
>   FiltersPoints
>   FiltersProgrammable
>   FiltersTexture
>   FiltersVerdict
>   GeovisCore
>   IOExodus
>   IOExport
>   # IOFFMPEG # Optional
>   IOImport
>   IOInfovis
>   # IOMySQL # Optional
>   IOPLY
>   IOParallel
>   IOParallelXML
>   ImagingColor
>   ImagingFourier
>   ImagingHybrid
>   ImagingMath
>   ImagingMorphological
>   ImagingSources
>   ImagingStatistics
>   ImagingStencil
>   # InfovisBoostGraphAlgorithms # Optional
>   InfovisLayout
>   InteractionImage
>   RenderingAnnotation
>   RenderingContextOpenGL2
>   RenderingImage
>   RenderingLOD
>   RenderingLabel
>   RenderingOpenGL2
>   RenderingVolumeOpenGL2
>   TestingGenericBridge
>   TestingRendering
>   ViewsContext2D
>   ViewsInfovis
> )
> endif ()
> add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
>
> On Thu, Jan 10, 2019 at 4:06 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
> >
> > I'm not specifying any components. If add the required components it works.
> > Before, I did not have to specify components... This is troublesome.
> >
> > Bill
> >
> > On Thu, Jan 10, 2019 at 3:27 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
> > >
> > > VTK_LIBRARIES is empty.
> > >
> > >
> > >
> > > On Jan 10, 2019 3:07 PM, "Ben Boeckel" <ben.boeckel at kitware.com> wrote:
> > >
> > > On Thu, Jan 10, 2019 at 14:08:28 -0800, Bill Lorensen wrote:
> > > > I have a simple program that fails to find the vtk include files:
> > > > Here is the CMakeLists.txt fiile:
> > > > cmake_minimum_required(VERSION 3.8)
> > > >
> > > > PROJECT(ReadOBJ)
> > > > Find_package(VTK)
> > > > if (VTK_VERSION VERSION_LESS "8.90")
> > > >   # old system
> > > >   include(${VTK_USE_FILE})
> > > >   # modules are linked via `vtkCommonCore`
> > > >   # VTK_DEFINITIONS has autoinit information
> > > > else ()
> > > >   # modules are linked via `VTK::CommonCore`
> > > >   # vtk_module_autoinit is needed
> > > > endif ()
> > > >
> > > > add_executable(ReadOBJ MACOSX_BUNDLE ReadOBJ.cxx )
> > > > target_link_libraries(ReadOBJ ${VTK_LIBRARIES})
> > >
> > > Hmm. What is `VTK_LIBRARIES` set to?
> > >
> > >
> > > --Ben
> > >
> > >
> >
> >
> > --
> > Unpaid intern in BillsParadise at noware dot com
>
>
>
> --
> Unpaid intern in BillsParadise at noware dot com



-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Fri Jan 11 09:24:48 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 09:24:48 -0500
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <CADZJ4hOtjZnmt8w75_14dzrOVEa=ZvWFh7Vicy5hMvTv3iPttg@mail.gmail.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
 <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
 <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>
 <CADZJ4hOtjZnmt8w75_14dzrOVEa=ZvWFh7Vicy5hMvTv3iPttg@mail.gmail.com>
Message-ID: <20190111142448.GB7191@megas.kitware.com>

On Thu, Jan 10, 2019 at 16:12:26 -0800, Bill Lorensen wrote:
> Is there a VTK cmake variable that lists all components in a particular build?

Not from `find_package(VTK)` directly. Currently testing if a component
is available is `if (TARGET VTK::${component})`.

> On Thu, Jan 10, 2019 at 4:10 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
> >   # FiltersParallelStatistics #  Optional

You can use `OPTIONAL_COMPONENTS` for these.

> > > On Thu, Jan 10, 2019 at 3:27 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
> > > > VTK_LIBRARIES is empty.

OK, that's a bug. Will make an MR today.

--Ben

From aron.helser at kitware.com  Fri Jan 11 09:30:01 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Fri, 11 Jan 2019 09:30:01 -0500
Subject: [vtk-developers] FindPackage not working in new module system
In-Reply-To: <20190110220806.GB21739@megas.kitware.com>
References: <CADZJ4hOOA0yt=8mo+v+mB871TGXkZUvXEi7TQ7ti0=Lgbr0WVg@mail.gmail.com>
 <20190109200640.GA24952@megas.kitware.com>
 <CAF2skS5PV1w7+8m1mGYiVyB2LNLNMP72UUW4wghrBJjcPCGtDA@mail.gmail.com>
 <CAF2skS5KQ1TxC9LqbD98ZM+PVoAPB6vikjPytAqKJRr5Bisefw@mail.gmail.com>
 <20190110183723.GA22349@megas.kitware.com>
 <CAF2skS6ttBoQD24i=WtvSBU+ADGnS1Wx_bwnj_sNL+G4cVLgwQ@mail.gmail.com>
 <20190110195027.GB29798@megas.kitware.com>
 <20190110220806.GB21739@megas.kitware.com>
Message-ID: <CAF2skS6JoV2i-gK1b4XWcRKF=ErhRPYvQTVbe1p4fnso+FEKeg@mail.gmail.com>

Awesome, thanks!

On Thu, Jan 10, 2019 at 5:08 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Thu, Jan 10, 2019 at 14:50:27 -0500, Ben Boeckel wrote:
> > On Thu, Jan 10, 2019 at 14:01:59 -0500, Aron Helser wrote:
> > > But my app compiles! So I'm not sure about the warning?
> >
> > It's a policy warning. We could set it in `vtk-config.cmake` since the
> > modules VTK is using should be policy-clean here. A policy scope should
> > be used though.
>
> This and the component name compatibility have been added here:
>
>     https://gitlab.kitware.com/vtk/vtk/merge_requests/5056
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/521fb21f/attachment.html>

From ben.boeckel at kitware.com  Fri Jan 11 09:35:42 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 09:35:42 -0500
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <20190111142448.GB7191@megas.kitware.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
 <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
 <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>
 <CADZJ4hOtjZnmt8w75_14dzrOVEa=ZvWFh7Vicy5hMvTv3iPttg@mail.gmail.com>
 <20190111142448.GB7191@megas.kitware.com>
Message-ID: <20190111143542.GA21302@megas.kitware.com>

On Fri, Jan 11, 2019 at 09:24:48 -0500, Ben Boeckel wrote:
> OK, that's a bug. Will make an MR today.

Note that using VTK_LIBRARIES when not specifying components leads to
linking *all* of VTK's modules. I wouldn't recommend this for
deployments using VTK since you might end up linking Java, Python, and
other third party libraries. Probably fine for example builds though.

--Ben

From bill.lorensen at gmail.com  Fri Jan 11 10:59:05 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 07:59:05 -0800
Subject: [vtk-developers] Missing Includes with new module system
In-Reply-To: <20190111143542.GA21302@megas.kitware.com>
References: <CADZJ4hP4UsM5zDkcgWsdioir=D5BqaiR+H-FxATxYp1wdh+1+g@mail.gmail.com>
 <20190110230719.GA7191@megas.kitware.com>
 <CADZJ4hMaWr_+stPk=JjWBLqFz6JMe+Ya+ScgkRs0+wB_DwS8MQ@mail.gmail.com>
 <CADZJ4hPwhmrF98sFNDVREV==iU+rsp-+dFqHd=rDbB597rfMRA@mail.gmail.com>
 <CADZJ4hOOJr_TUtG6gkZ-aWCHrw4e9+BXK-s8o3ASqe-dzo9ooQ@mail.gmail.com>
 <CADZJ4hOtjZnmt8w75_14dzrOVEa=ZvWFh7Vicy5hMvTv3iPttg@mail.gmail.com>
 <20190111142448.GB7191@megas.kitware.com>
 <20190111143542.GA21302@megas.kitware.com>
Message-ID: <CADZJ4hPM9d2E1BNBDv62SkD=jEyd=_G=R8UoRabu0as4PnR_5Q@mail.gmail.com>

Great. Looking forward to the MR.

On Fri, Jan 11, 2019, 6:35 AM Ben Boeckel <ben.boeckel at kitware.com wrote:

> On Fri, Jan 11, 2019 at 09:24:48 -0500, Ben Boeckel wrote:
> > OK, that's a bug. Will make an MR today.
>
> Note that using VTK_LIBRARIES when not specifying components leads to
> linking *all* of VTK's modules. I wouldn't recommend this for
> deployments using VTK since you might end up linking Java, Python, and
> other third party libraries. Probably fine for example builds though.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/b8326e95/attachment.html>

From elvis.stansvik at orexplore.com  Fri Jan 11 11:41:09 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 17:41:09 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py (new
 module system)?
Message-ID: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>

Hi Ben, all,

I quickly checked out master to see what
Utilities/Maintenance/WhatModulesVTK.py output would look like on our
code base as compared to before the module system merge. BTW many
thanks Ben for taking the effort to keep this script working!

Before (51a3c689c639e6936b0b479ffb0f7085468c0940):

All modules referenced in the files:
find_package(VTK COMPONENTS
  vtkChartsCore
  vtkCommonCore
  vtkCommonDataModel
  vtkCommonExecutionModel
  vtkCommonMath
  vtkCommonTransforms
  vtkFiltersCore
  vtkFiltersSources
  vtkGUISupportQt
  vtkIOImage
  vtkImagingCore
  vtkInteractionStyle
  vtkRenderingContext2D
  vtkRenderingCore
  vtkRenderingFreeType
  vtkRenderingFreeTypeFontConfig
  vtkRenderingOpenGL2
  vtkRenderingQt
  vtkRenderingVolume
  vtkRenderingVolumeOpenGL2
  vtkViewsContext2D
  vtkViewsCore
  vtkfreetype
  vtkkwiml
)

After (master):

All modules referenced in the files:
find_package(VTK COMPONENTS
  ChartsCore
  CommonCore
  CommonDataModel
  CommonExecutionModel
  CommonMath
  CommonTransforms
  FiltersCore
  FiltersSources
  GUISupportQt
  IOImage
  ImagingCore
  InteractionStyle
  RenderingContext2D
  RenderingCore
  RenderingFreeType
  RenderingOpenGL2
  RenderingQt
  RenderingVolume
  ViewsContext2D
  ViewsCore
  freetype
  kwiml
)

Nothing surprising, except:

  vtkRenderingFreeTypeFontConfig
  vtkRenderingVolumeOpenGL2

These are present before, but has no corresponding lines after the
merge. We make use of both.

Any ideas Ben? Is this expected or is there something fishy here.

Cheers,
Elvis

From ben.boeckel at kitware.com  Fri Jan 11 11:47:23 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 11:47:23 -0500
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
Message-ID: <20190111164723.GA21417@megas.kitware.com>

On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> Nothing surprising, except:
> 
>   vtkRenderingFreeTypeFontConfig
>   vtkRenderingVolumeOpenGL2
> 
> These are present before, but has no corresponding lines after the
> merge. We make use of both.
> 
> Any ideas Ben? Is this expected or is there something fishy here.

If the headers are not included explicitly, the script will miss it. I
think the right way to do this would be to collect `IMPLEMENTABLE` and
`IMPLEMENTS` bits and warn that modules which have object factories may
be missing implementations (with hints as which modules implement each
module with).

There had been "magical" knowledge embedded in the script that I removed
in commit 9437f76db782c48ebaae303c0e2f472147a3e712.

Another (future) enhancement would be to have it work with an installed
VTK (or any other VTK-module providing package really) rather than
forcing a VTK source tree to be present. It also wouldn't hint modules
which were not built. This is a much harder problem since it would need
to parse and understand CMake code.

--Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 12:24:54 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 18:24:54 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111164723.GA21417@megas.kitware.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
Message-ID: <CAE-7VJkNG-V0QVukYeJk0WbA0v_CprTkbHzhNDCRpRUMsY-Xfw@mail.gmail.com>

Alright, thanks for clarifying Ben. I do believe we are directly including
headers though, at least for the vtkFreeTypeFontConfig case. But I'll
double check.

Otherwise I'll just add these manually (keeping the magic knowledge in my
head :)).

The future enhancement you mentioned sounds like a fun project. Perhaps
CMake server mode can be leveraged?

Elvis

Den fre 11 jan. 2019 17:47Ben Boeckel <ben.boeckel at kitware.com> skrev:

> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> > Nothing surprising, except:
> >
> >   vtkRenderingFreeTypeFontConfig
> >   vtkRenderingVolumeOpenGL2
> >
> > These are present before, but has no corresponding lines after the
> > merge. We make use of both.
> >
> > Any ideas Ben? Is this expected or is there something fishy here.
>
> If the headers are not included explicitly, the script will miss it. I
> think the right way to do this would be to collect `IMPLEMENTABLE` and
> `IMPLEMENTS` bits and warn that modules which have object factories may
> be missing implementations (with hints as which modules implement each
> module with).
>
> There had been "magical" knowledge embedded in the script that I removed
> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>
> Another (future) enhancement would be to have it work with an installed
> VTK (or any other VTK-module providing package really) rather than
> forcing a VTK source tree to be present. It also wouldn't hint modules
> which were not built. This is a much harder problem since it would need
> to parse and understand CMake code.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/29c3a119/attachment.html>

From elvis.stansvik at orexplore.com  Fri Jan 11 12:38:57 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 18:38:57 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAE-7VJkNG-V0QVukYeJk0WbA0v_CprTkbHzhNDCRpRUMsY-Xfw@mail.gmail.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
 <CAE-7VJkNG-V0QVukYeJk0WbA0v_CprTkbHzhNDCRpRUMsY-Xfw@mail.gmail.com>
Message-ID: <CAE-7VJnJxPoM4RwLuY+fTW9bS_vch+zZPha-Pe+7ds=_Y1_2qw@mail.gmail.com>

Den fre 11 jan. 2019 kl 18:24 skrev Elvis Stansvik
<elvis.stansvik at orexplore.com>:
>
> Alright, thanks for clarifying Ben. I do believe we are directly including headers though, at least for the vtkFreeTypeFontConfig case. But I'll double check.

I was wrong, we were including vtkFreeTypeTools.h but not
vtkFontConfigFreeTypeTools.h, so makes sense that the
vtkFreeTypeFontConfig is now gone, if magic has been removed.

I guess the loss of vtkRenderingVolumeOpenGL2 is also due to removed magic..?

No worries, can live without it. We could make our own script which
imports WhatModulesVTK.py and adds these in for now.

Elvis

>
> Otherwise I'll just add these manually (keeping the magic knowledge in my head :)).
>
> The future enhancement you mentioned sounds like a fun project. Perhaps CMake server mode can be leveraged?
>
> Elvis
>
> Den fre 11 jan. 2019 17:47Ben Boeckel <ben.boeckel at kitware.com> skrev:
>>
>> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
>> > Nothing surprising, except:
>> >
>> >   vtkRenderingFreeTypeFontConfig
>> >   vtkRenderingVolumeOpenGL2
>> >
>> > These are present before, but has no corresponding lines after the
>> > merge. We make use of both.
>> >
>> > Any ideas Ben? Is this expected or is there something fishy here.
>>
>> If the headers are not included explicitly, the script will miss it. I
>> think the right way to do this would be to collect `IMPLEMENTABLE` and
>> `IMPLEMENTS` bits and warn that modules which have object factories may
>> be missing implementations (with hints as which modules implement each
>> module with).
>>
>> There had been "magical" knowledge embedded in the script that I removed
>> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>>
>> Another (future) enhancement would be to have it work with an installed
>> VTK (or any other VTK-module providing package really) rather than
>> forcing a VTK source tree to be present. It also wouldn't hint modules
>> which were not built. This is a much harder problem since it would need
>> to parse and understand CMake code.
>>
>> --Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 12:42:33 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 18:42:33 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111164723.GA21417@megas.kitware.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
Message-ID: <CAE-7VJnzY5=+qZXY0EPT8_y=-RLm7cELUzc2-vkaAP1HdG4+xA@mail.gmail.com>

Den fre 11 jan. 2019 kl 17:47 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> > Nothing surprising, except:
> >
> >   vtkRenderingFreeTypeFontConfig
> >   vtkRenderingVolumeOpenGL2
> >
> > These are present before, but has no corresponding lines after the
> > merge. We make use of both.
> >
> > Any ideas Ben? Is this expected or is there something fishy here.
>
> If the headers are not included explicitly, the script will miss it. I
> think the right way to do this would be to collect `IMPLEMENTABLE` and
> `IMPLEMENTS` bits and warn that modules which have object factories may
> be missing implementations (with hints as which modules implement each
> module with).
>
> There had been "magical" knowledge embedded in the script that I removed
> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>
> Another (future) enhancement would be to have it work with an installed
> VTK (or any other VTK-module providing package really) rather than
> forcing a VTK source tree to be present. It also wouldn't hint modules
> which were not built. This is a much harder problem since it would need
> to parse and understand CMake code.

Hm, thinking a bit more, is this even possible? After installation the
headers are all in the same directory, so there's no header -> module
information available..? If an installed layout like Qt's was used
(e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
I'm missing something..?

Elvis

>
> --Ben

From ben.boeckel at kitware.com  Fri Jan 11 12:57:47 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 12:57:47 -0500
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAE-7VJnzY5=+qZXY0EPT8_y=-RLm7cELUzc2-vkaAP1HdG4+xA@mail.gmail.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
 <CAE-7VJnzY5=+qZXY0EPT8_y=-RLm7cELUzc2-vkaAP1HdG4+xA@mail.gmail.com>
Message-ID: <20190111175747.GA9961@megas.kitware.com>

On Fri, Jan 11, 2019 at 18:42:33 +0100, Elvis Stansvik wrote:
> Hm, thinking a bit more, is this even possible? After installation the
> headers are all in the same directory, so there's no header -> module
> information available..? If an installed layout like Qt's was used
> (e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
> I'm missing something..?

The modules list what headers are associated with them in one of their
properties (this is for wrapping tools).

--Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 13:13:29 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 19:13:29 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111175747.GA9961@megas.kitware.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
 <CAE-7VJnzY5=+qZXY0EPT8_y=-RLm7cELUzc2-vkaAP1HdG4+xA@mail.gmail.com>
 <20190111175747.GA9961@megas.kitware.com>
Message-ID: <CAE-7VJmq06MdCCZYOQBWL9Hf3=PrympAFKUQiq=mXkZ3zRhTuw@mail.gmail.com>

Den fre 11 jan. 2019 kl 18:57 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Fri, Jan 11, 2019 at 18:42:33 +0100, Elvis Stansvik wrote:
> > Hm, thinking a bit more, is this even possible? After installation the
> > headers are all in the same directory, so there's no header -> module
> > information available..? If an installed layout like Qt's was used
> > (e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
> > I'm missing something..?
>
> The modules list what headers are associated with them in one of their
> properties (this is for wrapping tools).

Ah yes, but what about modules that are excluded from wrapping?

Elvis

>
> --Ben

From ben.boeckel at kitware.com  Fri Jan 11 13:30:42 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 13:30:42 -0500
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAE-7VJmq06MdCCZYOQBWL9Hf3=PrympAFKUQiq=mXkZ3zRhTuw@mail.gmail.com>
References: <CAE-7VJ=+F5eusDUkSrmoNWwVVB8P=3U0-bfcW+6i9+cve6hgHw@mail.gmail.com>
 <20190111164723.GA21417@megas.kitware.com>
 <CAE-7VJnzY5=+qZXY0EPT8_y=-RLm7cELUzc2-vkaAP1HdG4+xA@mail.gmail.com>
 <20190111175747.GA9961@megas.kitware.com>
 <CAE-7VJmq06MdCCZYOQBWL9Hf3=PrympAFKUQiq=mXkZ3zRhTuw@mail.gmail.com>
Message-ID: <20190111183042.GA1710@megas.kitware.com>

On Fri, Jan 11, 2019 at 19:13:29 +0100, Elvis Stansvik wrote:
> Ah yes, but what about modules that are excluded from wrapping?

Indeed. They do have that property skipped. This is at line
vtkModule.cmake:2997 (give or take). I actually am not sure how third
party libraries would appear here as well since they almost always have
a separate header installation step for the header VTK exposes for them
(e.g., `vtk_hdf5.h`).

--Ben

From bill.lorensen at gmail.com  Fri Jan 11 13:31:32 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 10:31:32 -0800
Subject: [vtk-developers] Lack of feedback during cache building
Message-ID: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>

If the cache is rebuilt, I do not get and feedback. Just
Configuring done

How to get the feedback we used to get?

-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Fri Jan 11 13:54:11 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 13:54:11 -0500
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
Message-ID: <20190111185411.GA22858@megas.kitware.com>

On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
> If the cache is rebuilt, I do not get and feedback. Just
> Configuring done
> 
> How to get the feedback we used to get?

What benefit did you derive from it? I always saw it as a wall of noise,
personally since it was unconditional and larger than a single screen
anyways.

I guess, what output should we be generating? For each bit: Should it be
unconditional? If not, should it be on by default?

--Ben

From bill.lorensen at gmail.com  Fri Jan 11 14:01:17 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 11:01:17 -0800
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <20190111185411.GA22858@megas.kitware.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
Message-ID: <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>

I like to see what modules might be excluded, etc. I'd like to see
something.

Is this the consensus?

On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com wrote:

> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
> > If the cache is rebuilt, I do not get and feedback. Just
> > Configuring done
> >
> > How to get the feedback we used to get?
>
> What benefit did you derive from it? I always saw it as a wall of noise,
> personally since it was unconditional and larger than a single screen
> anyways.
>
> I guess, what output should we be generating? For each bit: Should it be
> unconditional? If not, should it be on by default?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/ad485ef0/attachment.html>

From robert.maynard at kitware.com  Fri Jan 11 14:06:18 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 11 Jan 2019 14:06:18 -0500
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
Message-ID: <CAFzjYVo-Wu0R1awYZwABVYDBWwb1nJEzfH1RaAxTkyv08DthJA@mail.gmail.com>

I personally like not seeing as few details as possible.

Maybe just report what modules are enabled?

On Fri, Jan 11, 2019 at 2:01 PM Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> I like to see what modules might be excluded, etc. I'd like to see
> something.
>
> Is this the consensus?
>
> On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com wrote:
>
>> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
>> > If the cache is rebuilt, I do not get and feedback. Just
>> > Configuring done
>> >
>> > How to get the feedback we used to get?
>>
>> What benefit did you derive from it? I always saw it as a wall of noise,
>> personally since it was unconditional and larger than a single screen
>> anyways.
>>
>> I guess, what output should we be generating? For each bit: Should it be
>> unconditional? If not, should it be on by default?
>>
>> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/6fe40907/attachment.html>

From dave.demarle at kitware.com  Fri Jan 11 14:16:30 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 11 Jan 2019 14:16:30 -0500
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CAFzjYVo-Wu0R1awYZwABVYDBWwb1nJEzfH1RaAxTkyv08DthJA@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
 <CAFzjYVo-Wu0R1awYZwABVYDBWwb1nJEzfH1RaAxTkyv08DthJA@mail.gmail.com>
Message-ID: <CANjZAi_FKF9=21XkG2stt1X9QsX8KWLa24dtHsagGoLrOMnbXw@mail.gmail.com>

My preference is only error and warning messages.

David E DeMarle
Kitware, Inc.
Principal Engineer


On Fri, Jan 11, 2019 at 2:06 PM Robert Maynard via vtk-developers <
vtk-developers at vtk.org> wrote:

> I personally like not seeing as few details as possible.
>
> Maybe just report what modules are enabled?
>
> On Fri, Jan 11, 2019 at 2:01 PM Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> I like to see what modules might be excluded, etc. I'd like to see
>> something.
>>
>> Is this the consensus?
>>
>> On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com
>> wrote:
>>
>>> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
>>> > If the cache is rebuilt, I do not get and feedback. Just
>>> > Configuring done
>>> >
>>> > How to get the feedback we used to get?
>>>
>>> What benefit did you derive from it? I always saw it as a wall of noise,
>>> personally since it was unconditional and larger than a single screen
>>> anyways.
>>>
>>> I guess, what output should we be generating? For each bit: Should it be
>>> unconditional? If not, should it be on by default?
>>>
>>> --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://vtk.org/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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/dd6e4aca/attachment.html>

From bill.lorensen at gmail.com  Fri Jan 11 14:27:01 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 11:27:01 -0800
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CAFzjYVo-Wu0R1awYZwABVYDBWwb1nJEzfH1RaAxTkyv08DthJA@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
 <CAFzjYVo-Wu0R1awYZwABVYDBWwb1nJEzfH1RaAxTkyv08DthJA@mail.gmail.com>
Message-ID: <CADZJ4hOSDC2h-VqWm7M063JJATNrD7DqO=hKUe54+-+1FRKKyw@mail.gmail.com>

Why cant we have a flag that will give the feedback we used to have? Or a
make variable?

On Fri, Jan 11, 2019, 11:06 AM Robert Maynard <robert.maynard at kitware.com
wrote:

> I personally like not seeing as few details as possible.
>
> Maybe just report what modules are enabled?
>
> On Fri, Jan 11, 2019 at 2:01 PM Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> I like to see what modules might be excluded, etc. I'd like to see
>> something.
>>
>> Is this the consensus?
>>
>> On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com
>> wrote:
>>
>>> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
>>> > If the cache is rebuilt, I do not get and feedback. Just
>>> > Configuring done
>>> >
>>> > How to get the feedback we used to get?
>>>
>>> What benefit did you derive from it? I always saw it as a wall of noise,
>>> personally since it was unconditional and larger than a single screen
>>> anyways.
>>>
>>> I guess, what output should we be generating? For each bit: Should it be
>>> unconditional? If not, should it be on by default?
>>>
>>> --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://vtk.org/mailman/listinfo/vtk-developers
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/a795fd72/attachment-0001.html>

From elvis.stansvik at orexplore.com  Fri Jan 11 14:30:38 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 20:30:38 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu 18.04
Message-ID: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>

Hi all,

Previously I had successfully used (VTK master from some months ago):

cmake \
    -DCMAKE_INSTALL_PREFIX=/opt/VTK9 \
    -DCMAKE_INSTALL_RPATH=/opt/VTK9/lib \
    -DVTK_Group_Qt=ON \
    -DVTK_QT_VERSION=5 \
    -DVTK_Group_Imaging=ON \
    -DVTK_Group_Views=ON \
    -DModule_vtkRenderingFreeTypeFontConfig=ON \
    -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 \
    -DBUILD_TESTING=OFF \
    -DVTK_USE_SYSTEM_LIBRARIES=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 \
    -DCMAKE_BUILD_TYPE=None \
    ..

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 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?

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?

Elvis

From ben.boeckel at kitware.com  Fri Jan 11 14:34:45 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 14:34:45 -0500
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
Message-ID: <20190111193445.GA10329@rotor.localdomain>

On Fri, Jan 11, 2019 at 11:01:17 -0800, Bill Lorensen wrote:
> I like to see what modules might be excluded, etc. I'd like to see
> something.
> 
> Is this the consensus?

There is an item to add debugging information to help figure out why a
module is on or off (same with testing). Something like
`-Dvtk_module_debug=module;testing` would do it. VTK could expose nicer
booleans for such internals too.

--Ben

From sean at rogue-research.com  Fri Jan 11 14:59:23 2019
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 11 Jan 2019 14:59:23 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
Message-ID: <20190111195923.2117407654@mail.rogue-research.com>

Hi all,

In cmake I set CMAKE_CXX_FLAGS to "-std=c++2a" but when I do "make VERBOSE=1" I see that something is passing -std=c++11:

cd /Users/sean/external/VTK-8bin/Common/Core && /Users/sean/llvm/llvm-rel-install/bin/clang++  -DVTK_IN_VTK -DvtkCommonCore_EXPORTS -I/Users/sean/external/VTK-8bin/Common/DataModel -I/Users/sean/external/VTK-8bin/Common/Core -I/Users/sean/external/VTK/Common/Core -I/Users/sean/external/VTK-8bin/Utilities/KWIML -I/Users/sean/external/VTK/Utilities/KWIML -I/Users/sean/external/VTK-8bin/Utilities/KWSys -I/Users/sean/external/VTK/Utilities/KWSys -I/Users/sean/external/VTK-8bin/ThirdParty/utf8 -I/Users/sean/external/VTK/ThirdParty/utf8  -std=c++2a  -g -fPIC -fvisibility=hidden   -std=c++11 -o CMakeFiles/vtkCommonCore.dir/vtkAbstractArray.cxx.o -c /Users/sean/external/VTK/Common/Core/vtkAbstractArray.cxx

Is this a bug?  If not, how do I specify the language variant?

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From brad.king at kitware.com  Fri Jan 11 15:04:21 2019
From: brad.king at kitware.com (Brad King)
Date: Fri, 11 Jan 2019 15:04:21 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <20190111195923.2117407654@mail.rogue-research.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
Message-ID: <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>

On 1/11/19 2:59 PM, Sean McBride wrote:
> In cmake I set CMAKE_CXX_FLAGS to "-std=c++2a" but when I do "make VERBOSE=1"
> I see that something is passing -std=c++11:
> 
> Is this a bug?  If not, how do I specify the language variant?

It's likely CMake adding it based on Common/Core/CMakeLists.txt:

```
vtk_module_compile_features(VTK::CommonCore
  PUBLIC
    cxx_std_11
    cxx_nullptr
    cxx_override)
```

There is an open CMake issue about handling future standards:

  https://gitlab.kitware.com/cmake/cmake/issues/17146#note_300071

Lacking a full solution in CMake, VTK could gain an option to not
specify these feature requirements.

-Brad

From robert.maynard at kitware.com  Fri Jan 11 15:08:56 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 11 Jan 2019 15:08:56 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
 <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
Message-ID: <CAFzjYVrw=S+mjuTRVeEac2-SQsP-PbPWo1L9BmT-0jSsRzo_gw@mail.gmail.com>

Adding an option to VTK to not specify these features will also need to be
propagated to all thirdpary libraries that use things such as `cxx_std_11`
( aka VTK-m ).



On Fri, Jan 11, 2019 at 3:04 PM Brad King via vtk-developers <
vtk-developers at vtk.org> wrote:

> On 1/11/19 2:59 PM, Sean McBride wrote:
> > In cmake I set CMAKE_CXX_FLAGS to "-std=c++2a" but when I do "make
> VERBOSE=1"
> > I see that something is passing -std=c++11:
> >
> > Is this a bug?  If not, how do I specify the language variant?
>
> It's likely CMake adding it based on Common/Core/CMakeLists.txt:
>
> ```
> vtk_module_compile_features(VTK::CommonCore
>   PUBLIC
>     cxx_std_11
>     cxx_nullptr
>     cxx_override)
> ```
>
> There is an open CMake issue about handling future standards:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/17146#note_300071
>
> Lacking a full solution in CMake, VTK could gain an option to not
> specify these feature requirements.
>
> -Brad
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/878355a8/attachment.html>

From andrew.amaclean at gmail.com  Fri Jan 11 15:13:02 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 12 Jan 2019 07:13:02 +1100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
Message-ID: <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>

I am surprised and amazed this works with the new system.
When I wrote it, it:
1) Only looked at the header files in your code and, from their name,
worked out the module to use. Ad a consequence of this we had to manually
include e.g. some modules like the OpenGL stuff.
2) Does detect modules excluded from the wrapping.
3) It was written before external modules were introduced so it may not
properly work with them.

The intent was to provide to the user a guide as to what modules should be
included so they may still have to add extras.

Andrew



>
> ---------- Forwarded message ----------
> From: Ben Boeckel <ben.boeckel at kitware.com>
> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
> Cc: vtkdev <vtk-developers at vtk.org>
> Bcc:
> Date: Fri, 11 Jan 2019 13:30:42 -0500
> Subject: Re: [vtk-developers] Slight behavioral change in
> WhatModulesVTK.py (new module system)?
> On Fri, Jan 11, 2019 at 19:13:29 +0100, Elvis Stansvik wrote:
> > Ah yes, but what about modules that are excluded from wrapping?
>
> Indeed. They do have that property skipped. This is at line
> vtkModule.cmake:2997 (give or take). I actually am not sure how third
> party libraries would appear here as well since they almost always have
> a separate header installation step for the header VTK exposes for them
> (e.g., `vtk_hdf5.h`).
>
> --Ben
>
>
>
> --
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/ba3ee9b5/attachment-0001.html>

From sean at rogue-research.com  Fri Jan 11 15:14:22 2019
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 11 Jan 2019 15:14:22 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
 <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
Message-ID: <20190111201422.876359131@mail.rogue-research.com>

On Fri, 11 Jan 2019 15:04:21 -0500, Brad King said:

>On 1/11/19 2:59 PM, Sean McBride wrote:
>> In cmake I set CMAKE_CXX_FLAGS to "-std=c++2a" but when I do "make
>VERBOSE=1"
>> I see that something is passing -std=c++11:
>> 
>> Is this a bug?  If not, how do I specify the language variant?
>
>It's likely CMake adding it based on Common/Core/CMakeLists.txt:
>
>```
>vtk_module_compile_features(VTK::CommonCore
>  PUBLIC
>    cxx_std_11
>    cxx_nullptr
>    cxx_override)
>```
>
>There is an open CMake issue about handling future standards:
>
>  https://gitlab.kitware.com/cmake/cmake/issues/17146#note_300071

It doesn't seem to matter that I've specified a 'future standard', even if I use -std=c++14 I get:

cd /Users/sean/external/VTK-8bin/Utilities/KWIML/vtkkwiml/test && /Users/sean/llvm/llvm-rel-install/bin/clang++  -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -DVTK_IN_VTK -I/Users/sean/external/VTK-8bin/Utilities/KWIML -I/Users/sean/external/VTK/Utilities/KWIML  -std=c++14  -g   -std=c++11 -o CMakeFiles/kwiml_test.dir/test_include_CXX.cxx.o -c /Users/sean/external/VTK/Utilities/KWIML/vtkkwiml/test/test_include_CXX.cxx

Sean



From ben.boeckel at kitware.com  Fri Jan 11 15:21:43 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 15:21:43 -0500
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
Message-ID: <20190111202143.GA23985@rotor.localdomain>

On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> I am surprised and amazed this works with the new system.

I updated it since it was requested here. It also turned out to be quite
helpful for determining real dependencies of things in ParaView and
examples.

> When I wrote it, it:
> 1) Only looked at the header files in your code and, from their name,
> worked out the module to use. Ad a consequence of this we had to manually
> include e.g. some modules like the OpenGL stuff.

That's pretty much true still.

> 2) Does detect modules excluded from the wrapping.

Not hard now; it's still just a keyword in `vtk.module`. Though it
doesn't do so right now.

> 3) It was written before external modules were introduced so it may not
> properly work with them.

It only cares about `vtk.module` files (just like it cared only about
`module.cmake` before. If it can find them in the path given, I don't
think it should matter too much.

> The intent was to provide to the user a guide as to what modules should be
> included so they may still have to add extras.

Yeah. I imagine the hard-coded if-then extensions were done because of
this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
any module.

--Ben

From andrew.amaclean at gmail.com  Fri Jan 11 15:26:06 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 12 Jan 2019 07:26:06 +1100
Subject: [vtk-developers] 
 =?utf-8?q?=E2=80=8BMissing_Includes_with_new_mo?=
 =?utf-8?q?dule_system?=
In-Reply-To: <mailman.420.1547224884.2633.vtk-developers@vtk.org>
References: <mailman.420.1547224884.2633.vtk-developers@vtk.org>
Message-ID: <CAHDsG9ObrVLuJBAtRPbxaaK5QFuUY86-bCdMgHcRmPQUZE9+RA@mail.gmail.com>

It would be nice to have a VTK variable that lists the VTK C++ specific
modules that VTK was built with.
This would make Bill's generic CMake lists script on the web page really
simple and less daunting for new users running the examples.
It also gives new users a quick way to get their code up and running.

Regards
   Andrew



> ---------- Forwarded message ----------
> From: Ben Boeckel <ben.boeckel at kitware.com>
> To: Bill Lorensen <bill.lorensen at gmail.com>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Bcc:
> Date: Fri, 11 Jan 2019 09:35:42 -0500
> Subject: Re: [vtk-developers] Missing Includes with new module system
> On Fri, Jan 11, 2019 at 09:24:48 -0500, Ben Boeckel wrote:
> > OK, that's a bug. Will make an MR today.
>
> Note that using VTK_LIBRARIES when not specifying components leads to
> linking *all* of VTK's modules. I wouldn't recommend this for
> deployments using VTK since you might end up linking Java, Python, and
> other third party libraries. Probably fine for example builds though.
>
> --Ben
>
>
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/8d514a26/attachment.html>

From ben.boeckel at kitware.com  Fri Jan 11 15:28:43 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 15:28:43 -0500
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
Message-ID: <20190111202843.GB23985@rotor.localdomain>

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.

> 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

> 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).

--Ben

From andrew.amaclean at gmail.com  Fri Jan 11 15:32:01 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 12 Jan 2019 07:32:01 +1100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111202143.GA23985@rotor.localdomain>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
 <20190111202143.GA23985@rotor.localdomain>
Message-ID: <CAHDsG9MH4PuRhq+Bfon1-suEQQ6LZ5FfkKaH-N0g8zCXgEBdqw@mail.gmail.com>

Ben,
I was actually thinking of having a look at it last night because of all
the changes. Thanks for already doing this!

Much appreciated.

Regards
   Andrew


On Sat, Jan 12, 2019 at 7:21 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > I am surprised and amazed this works with the new system.
>
> I updated it since it was requested here. It also turned out to be quite
> helpful for determining real dependencies of things in ParaView and
> examples.
>
> > When I wrote it, it:
> > 1) Only looked at the header files in your code and, from their name,
> > worked out the module to use. Ad a consequence of this we had to manually
> > include e.g. some modules like the OpenGL stuff.
>
> That's pretty much true still.
>
> > 2) Does detect modules excluded from the wrapping.
>
> Not hard now; it's still just a keyword in `vtk.module`. Though it
> doesn't do so right now.
>
> > 3) It was written before external modules were introduced so it may not
> > properly work with them.
>
> It only cares about `vtk.module` files (just like it cared only about
> `module.cmake` before. If it can find them in the path given, I don't
> think it should matter too much.
>
> > The intent was to provide to the user a guide as to what modules should
> be
> > included so they may still have to add extras.
>
> Yeah. I imagine the hard-coded if-then extensions were done because of
> this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> any module.
>
> --Ben
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/005e4cfb/attachment-0001.html>

From ben.boeckel at kitware.com  Fri Jan 11 15:34:13 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 15:34:13 -0500
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <20190111202843.GB23985@rotor.localdomain>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
Message-ID: <20190111203413.GA2338@rotor.localdomain>

On Fri, Jan 11, 2019 at 15:28:43 -0500, Ben Boeckel wrote:
>     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.

Nevermind, was looking at an old checkout. It is already done :) .

--Ben

From ben.boeckel at kitware.com  Fri Jan 11 15:35:45 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 15:35:45 -0500
Subject: [vtk-developers] 
 =?utf-8?q?=E2=80=8BMissing_Includes_with_new_mo?=
 =?utf-8?q?dule_system?=
In-Reply-To: <CAHDsG9ObrVLuJBAtRPbxaaK5QFuUY86-bCdMgHcRmPQUZE9+RA@mail.gmail.com>
References: <mailman.420.1547224884.2633.vtk-developers@vtk.org>
 <CAHDsG9ObrVLuJBAtRPbxaaK5QFuUY86-bCdMgHcRmPQUZE9+RA@mail.gmail.com>
Message-ID: <20190111203545.GB2338@rotor.localdomain>

On Sat, Jan 12, 2019 at 07:26:06 +1100, Andrew Maclean wrote:
> It would be nice to have a VTK variable that lists the VTK C++ specific
> modules that VTK was built with.
> This would make Bill's generic CMake lists script on the web page really
> simple and less daunting for new users running the examples.
> It also gives new users a quick way to get their code up and running.

VTK_AVAILABLE_COMPONENTS is set given this MR:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5057

--Ben

From andrew.amaclean at gmail.com  Fri Jan 11 15:46:08 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 12 Jan 2019 07:46:08 +1100
Subject: [vtk-developers] 
 =?utf-8?q?=E2=80=8BMissing_Includes_with_new_mo?=
 =?utf-8?q?dule_system?=
In-Reply-To: <20190111203545.GB2338@rotor.localdomain>
References: <mailman.420.1547224884.2633.vtk-developers@vtk.org>
 <CAHDsG9ObrVLuJBAtRPbxaaK5QFuUY86-bCdMgHcRmPQUZE9+RA@mail.gmail.com>
 <20190111203545.GB2338@rotor.localdomain>
Message-ID: <CAHDsG9NuXKzuX-o7-j2ev76=Wz-iZEQO+t50B433YxcA08og=w@mail.gmail.com>

Awesome, thanks!
That is a good name for it.
I'll let Bill check it out.
I have been busy cleaning up and updating all the Python examples to make
sure they all work and have nice images where appropriate.
So I haven updated VTK yet.

Regards
   Andrew



On Sat, Jan 12, 2019 at 7:35 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Sat, Jan 12, 2019 at 07:26:06 +1100, Andrew Maclean wrote:
> > It would be nice to have a VTK variable that lists the VTK C++ specific
> > modules that VTK was built with.
> > This would make Bill's generic CMake lists script on the web page really
> > simple and less daunting for new users running the examples.
> > It also gives new users a quick way to get their code up and running.
>
> VTK_AVAILABLE_COMPONENTS is set given this MR:
>
>     https://gitlab.kitware.com/vtk/vtk/merge_requests/5057
>
> --Ben
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/57c5d439/attachment.html>

From elvis.stansvik at orexplore.com  Fri Jan 11 15:49:31 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 21:49:31 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <20190111202843.GB23985@rotor.localdomain>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
Message-ID: <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>

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

From elvis.stansvik at orexplore.com  Fri Jan 11 16:03:15 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:03:15 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111202143.GA23985@rotor.localdomain>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
 <20190111202143.GA23985@rotor.localdomain>
Message-ID: <CAE-7VJnBAGOf0tPxqG1eu0WM_5GjU8Ogjnd3=DAPi1G7VkqvXg@mail.gmail.com>

Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > I am surprised and amazed this works with the new system.
>
> I updated it since it was requested here. It also turned out to be quite
> helpful for determining real dependencies of things in ParaView and
> examples.
>
> > When I wrote it, it:
> > 1) Only looked at the header files in your code and, from their name,
> > worked out the module to use. Ad a consequence of this we had to manually
> > include e.g. some modules like the OpenGL stuff.
>
> That's pretty much true still.
>
> > 2) Does detect modules excluded from the wrapping.
>
> Not hard now; it's still just a keyword in `vtk.module`. Though it
> doesn't do so right now.
>
> > 3) It was written before external modules were introduced so it may not
> > properly work with them.
>
> It only cares about `vtk.module` files (just like it cared only about
> `module.cmake` before. If it can find them in the path given, I don't
> think it should matter too much.
>
> > The intent was to provide to the user a guide as to what modules should be
> > included so they may still have to add extras.

Yep, we always did have to tweak it a bit and that's OK, it's very
useful nonetheless.

I run the script from time to time (not that often), just to check
that the list of modules we link against is accurate wrt to the code.

Elvis

>
> Yeah. I imagine the hard-coded if-then extensions were done because of
> this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> any module.
>
> --Ben

From ben.boeckel at kitware.com  Fri Jan 11 16:04:52 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 16:04:52 -0500
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
Message-ID: <20190111210452.GB8874@rotor.localdomain>

On Fri, Jan 11, 2019 at 21:49:31 +0100, Elvis Stansvik wrote:
> Den fre 11 jan. 2019 kl 21:28 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > 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?

Hmm, not sure. That block has always been active AFAICS. Maybe `eigen`
wasn't being built before?

--Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 16:07:25 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:07:25 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <20190111202143.GA23985@rotor.localdomain>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
 <20190111202143.GA23985@rotor.localdomain>
Message-ID: <CAE-7VJnPPs8=EqVDvW0gV0QSJ9BAbK91Ew41jHSR07VocMPGCQ@mail.gmail.com>

Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > I am surprised and amazed this works with the new system.
>
> I updated it since it was requested here. It also turned out to be quite
> helpful for determining real dependencies of things in ParaView and
> examples.

Maybe some day in the future, with the enhancements you had in mind
(working with installed VTK et.c.), it could be robust enough to be
used when generating the CMakeLists.txt for the examples, so they
could show "best practice" and not linking all of VTK (cf Bill's
recent thread).

Elvis

>
> > When I wrote it, it:
> > 1) Only looked at the header files in your code and, from their name,
> > worked out the module to use. Ad a consequence of this we had to manually
> > include e.g. some modules like the OpenGL stuff.
>
> That's pretty much true still.
>
> > 2) Does detect modules excluded from the wrapping.
>
> Not hard now; it's still just a keyword in `vtk.module`. Though it
> doesn't do so right now.
>
> > 3) It was written before external modules were introduced so it may not
> > properly work with them.
>
> It only cares about `vtk.module` files (just like it cared only about
> `module.cmake` before. If it can find them in the path given, I don't
> think it should matter too much.
>
> > The intent was to provide to the user a guide as to what modules should be
> > included so they may still have to add extras.
>
> Yeah. I imagine the hard-coded if-then extensions were done because of
> this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> any module.
>
> --Ben

From bill.lorensen at gmail.com  Fri Jan 11 16:12:52 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 13:12:52 -0800
Subject: [vtk-developers] 
 =?utf-8?q?=E2=80=8BMissing_Includes_with_new_mo?=
 =?utf-8?q?dule_system?=
In-Reply-To: <20190111203545.GB2338@rotor.localdomain>
References: <mailman.420.1547224884.2633.vtk-developers@vtk.org>
 <CAHDsG9ObrVLuJBAtRPbxaaK5QFuUY86-bCdMgHcRmPQUZE9+RA@mail.gmail.com>
 <20190111203545.GB2338@rotor.localdomain>
Message-ID: <CADZJ4hPELkeoR8N-LZou2LCKAfGxrZM0ysVEgZ4F1pd_-FT8-A@mail.gmail.com>

When I use
  Find_package(VTK COMPONENTS ${VTK_AVAILABLE_COMPONENTS})

cmake errrors;

CMake Error in CMakeLists.txt:

  Imported target "VTK::theora" includes non-existent path


    "/Users/lorensen/ProjectsGIT/VTKNewModules-clang/ThirdParty/theora/vtktheora/include"


  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:


  * The path was deleted, renamed, or moved to another location.


  * An install or uninstall procedure did not complete successfully.


  * The installation package was faulty and references files it does not

  provide.

From bill.lorensen at gmail.com  Fri Jan 11 16:20:20 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 13:20:20 -0800
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CAE-7VJnPPs8=EqVDvW0gV0QSJ9BAbK91Ew41jHSR07VocMPGCQ@mail.gmail.com>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
 <20190111202143.GA23985@rotor.localdomain>
 <CAE-7VJnPPs8=EqVDvW0gV0QSJ9BAbK91Ew41jHSR07VocMPGCQ@mail.gmail.com>
Message-ID: <CADZJ4hP7Q1AGQC8VdjwdiCeA-y4eTSPOvm=OmMyALNjaMKFx1Q@mail.gmail.com>

There are over 1000 C++ examples. The web page for each example (and
the associated tar file) is generated automatically for each example.
To generate an example-specific components list for each example would
be a challenge. For now, I'd rather modify the templates to include pf
all the modules.

When the entire collection of examples is built, either as a Remote
module or stand-alone, it would be more of a challenge to handle the
1000 examples. I don't think it is worth the effort for what little
would be gained.

On Fri, Jan 11, 2019 at 1:07 PM Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
>
> Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> >
> > On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > > I am surprised and amazed this works with the new system.
> >
> > I updated it since it was requested here. It also turned out to be quite
> > helpful for determining real dependencies of things in ParaView and
> > examples.
>
> Maybe some day in the future, with the enhancements you had in mind
> (working with installed VTK et.c.), it could be robust enough to be
> used when generating the CMakeLists.txt for the examples, so they
> could show "best practice" and not linking all of VTK (cf Bill's
> recent thread).
>
> Elvis
>
> >
> > > When I wrote it, it:
> > > 1) Only looked at the header files in your code and, from their name,
> > > worked out the module to use. Ad a consequence of this we had to manually
> > > include e.g. some modules like the OpenGL stuff.
> >
> > That's pretty much true still.
> >
> > > 2) Does detect modules excluded from the wrapping.
> >
> > Not hard now; it's still just a keyword in `vtk.module`. Though it
> > doesn't do so right now.
> >
> > > 3) It was written before external modules were introduced so it may not
> > > properly work with them.
> >
> > It only cares about `vtk.module` files (just like it cared only about
> > `module.cmake` before. If it can find them in the path given, I don't
> > think it should matter too much.
> >
> > > The intent was to provide to the user a guide as to what modules should be
> > > included so they may still have to add extras.
> >
> > Yeah. I imagine the hard-coded if-then extensions were done because of
> > this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> > any module.
> >
> > --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://vtk.org/mailman/listinfo/vtk-developers
>


-- 
Unpaid intern in BillsParadise at noware dot com

From elvis.stansvik at orexplore.com  Fri Jan 11 16:30:03 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:30:03 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <20190111210452.GB8874@rotor.localdomain>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
 <20190111210452.GB8874@rotor.localdomain>
Message-ID: <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>

Den fre 11 jan. 2019 kl 22:04 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Fri, Jan 11, 2019 at 21:49:31 +0100, Elvis Stansvik wrote:
> > Den fre 11 jan. 2019 kl 21:28 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > > 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?
>
> Hmm, not sure. That block has always been active AFAICS. Maybe `eigen`
> wasn't being built before?

Now following your suggestions with an amended CMake line:

[estan at newton VTK-build]$ cmake \
> -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
> -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
> -DVTK_GROUP_ENABLE_Qt=YES \
> -DVTK_GROUP_ENABLE_Imaging=YES \
> -DVTK_GROUP_ENABLE__Views=YES \
> -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
> -DVTK_BUILD_TESTING=ON \
> -DVTK_USE_EXTERNAL=YES \
> -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=ON \
> -DCMAKE_BUILD_TYPE=None \
> ../VTK
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
-- Performing Test Support for 64 bit file systems
-- Performing Test Support for 64 bit file systems - Success
CMake Error at CMake/vtkModule.cmake:811 (message):
  The VTK::IOExportGL2PS module requires the disabled module VTK::IOParallel.
Call Stack (most recent call first):
  CMakeLists.txt:197 (vtk_module_scan)


-- Configuring incomplete, errors occurred!
See also "/home/estan/orexplore/VTK-build/CMakeFiles/CMakeOutput.log".
[estan at newton VTK-build]$

I think I'm now past the trouble with eigen3, due to using the correct
VTK_USE_EXTERNAL (so it uses the system eigen), thanks!

But how about this error above? How can I find out why it disabled the
IOParallel module?

Elvis

>
> --Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 16:33:10 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:33:10 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
 <20190111210452.GB8874@rotor.localdomain>
 <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>
Message-ID: <CAE-7VJmrzUMf0UcE6os9w+98SJ6Tir0A4dqf7MYURQ_4dDC2rQ@mail.gmail.com>

Den fre 11 jan. 2019 kl 22:30 skrev Elvis Stansvik
<elvis.stansvik at orexplore.com>:
>
> Den fre 11 jan. 2019 kl 22:04 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> >
> > On Fri, Jan 11, 2019 at 21:49:31 +0100, Elvis Stansvik wrote:
> > > Den fre 11 jan. 2019 kl 21:28 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > > > 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?
> >
> > Hmm, not sure. That block has always been active AFAICS. Maybe `eigen`
> > wasn't being built before?
>
> Now following your suggestions with an amended CMake line:
>
> [estan at newton VTK-build]$ cmake \
> > -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
> > -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
> > -DVTK_GROUP_ENABLE_Qt=YES \
> > -DVTK_GROUP_ENABLE_Imaging=YES \
> > -DVTK_GROUP_ENABLE__Views=YES \
> > -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
> > -DVTK_BUILD_TESTING=ON \
> > -DVTK_USE_EXTERNAL=YES \
> > -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=ON \
> > -DCMAKE_BUILD_TYPE=None \
> > ../VTK
> -- The C compiler identification is GNU 7.3.0
> -- The CXX compiler identification is GNU 7.3.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
> -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
> -- Performing Test Support for 64 bit file systems
> -- Performing Test Support for 64 bit file systems - Success
> CMake Error at CMake/vtkModule.cmake:811 (message):
>   The VTK::IOExportGL2PS module requires the disabled module VTK::IOParallel.
> Call Stack (most recent call first):
>   CMakeLists.txt:197 (vtk_module_scan)
>
>
> -- Configuring incomplete, errors occurred!
> See also "/home/estan/orexplore/VTK-build/CMakeFiles/CMakeOutput.log".
> [estan at newton VTK-build]$
>
> I think I'm now past the trouble with eigen3, due to using the correct
> VTK_USE_EXTERNAL (so it uses the system eigen), thanks!
>
> But how about this error above? How can I find out why it disabled the
> IOParallel module?

Hm, I realized I accidentally enabled testing when updating the flags.
When I corrected it to -DVTK_BUILD_TESTING=OFF, the CMake got much
further. Strange...

Anyway, I'll probably get this working now.

Elvis

>
> Elvis
>
> >
> > --Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 16:39:21 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:39:21 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <CAE-7VJmrzUMf0UcE6os9w+98SJ6Tir0A4dqf7MYURQ_4dDC2rQ@mail.gmail.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
 <20190111210452.GB8874@rotor.localdomain>
 <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>
 <CAE-7VJmrzUMf0UcE6os9w+98SJ6Tir0A4dqf7MYURQ_4dDC2rQ@mail.gmail.com>
Message-ID: <CAE-7VJnam=Dfcuxxfh1Svbb01wa3ZZiM9k5Cvr3pomSADS37tA@mail.gmail.com>

Den fre 11 jan. 2019 kl 22:33 skrev Elvis Stansvik
<elvis.stansvik at orexplore.com>:
>
> Den fre 11 jan. 2019 kl 22:30 skrev Elvis Stansvik
> <elvis.stansvik at orexplore.com>:
> >
> > Den fre 11 jan. 2019 kl 22:04 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > >
> > > On Fri, Jan 11, 2019 at 21:49:31 +0100, Elvis Stansvik wrote:
> > > > Den fre 11 jan. 2019 kl 21:28 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > > > > 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?
> > >
> > > Hmm, not sure. That block has always been active AFAICS. Maybe `eigen`
> > > wasn't being built before?
> >
> > Now following your suggestions with an amended CMake line:
> >
> > [estan at newton VTK-build]$ cmake \
> > > -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
> > > -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
> > > -DVTK_GROUP_ENABLE_Qt=YES \
> > > -DVTK_GROUP_ENABLE_Imaging=YES \
> > > -DVTK_GROUP_ENABLE__Views=YES \
> > > -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
> > > -DVTK_BUILD_TESTING=ON \
> > > -DVTK_USE_EXTERNAL=YES \
> > > -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=ON \
> > > -DCMAKE_BUILD_TYPE=None \
> > > ../VTK
> > -- The C compiler identification is GNU 7.3.0
> > -- The CXX compiler identification is GNU 7.3.0
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
> > -- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
> > -- Performing Test Support for 64 bit file systems
> > -- Performing Test Support for 64 bit file systems - Success
> > CMake Error at CMake/vtkModule.cmake:811 (message):
> >   The VTK::IOExportGL2PS module requires the disabled module VTK::IOParallel.
> > Call Stack (most recent call first):
> >   CMakeLists.txt:197 (vtk_module_scan)
> >
> >
> > -- Configuring incomplete, errors occurred!
> > See also "/home/estan/orexplore/VTK-build/CMakeFiles/CMakeOutput.log".
> > [estan at newton VTK-build]$
> >
> > I think I'm now past the trouble with eigen3, due to using the correct
> > VTK_USE_EXTERNAL (so it uses the system eigen), thanks!
> >
> > But how about this error above? How can I find out why it disabled the
> > IOParallel module?
>
> Hm, I realized I accidentally enabled testing when updating the flags.
> When I corrected it to -DVTK_BUILD_TESTING=OFF, the CMake got much
> further. Strange...
>
> Anyway, I'll probably get this working now.

The golden line for me:

cmake \
    -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
    -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
    -DVTK_GROUP_ENABLE_Qt=YES \
    -DVTK_GROUP_ENABLE_Imaging=YES \
    -DVTK_GROUP_ENABLE_Views=YES \
    -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
    -DVTK_BUILD_TESTING=OFF \
    -DVTK_USE_EXTERNAL=YES \
    -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=OFF \
    -DVTK_MODULE_USE_EXTERNAL_VTK_libharu=OFF \
    -DCMAKE_BUILD_TYPE=None \
    ../VTK

I had made a bunch of mistakes earlier. This line worked fine, and
gl2ps and libharu were the only ones I needed to use the internal ones
(due to slightly too old versions in Ubuntu 18.04).

Many thanks Ben.

Elvis

>
> Elvis
>
> >
> > Elvis
> >
> > >
> > > --Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 16:54:25 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 11 Jan 2019 22:54:25 +0100
Subject: [vtk-developers] Slight behavioral change in WhatModulesVTK.py
 (new module system)?
In-Reply-To: <CADZJ4hP7Q1AGQC8VdjwdiCeA-y4eTSPOvm=OmMyALNjaMKFx1Q@mail.gmail.com>
References: <mailman.423.1547231505.2633.vtk-developers@vtk.org>
 <CAHDsG9MkS5to06Kd9jR05v0csst4JivOcH4Q_OsyO8QdRE6pgQ@mail.gmail.com>
 <20190111202143.GA23985@rotor.localdomain>
 <CAE-7VJnPPs8=EqVDvW0gV0QSJ9BAbK91Ew41jHSR07VocMPGCQ@mail.gmail.com>
 <CADZJ4hP7Q1AGQC8VdjwdiCeA-y4eTSPOvm=OmMyALNjaMKFx1Q@mail.gmail.com>
Message-ID: <CAE-7VJmw6_z9FQLSdLYr++eNB9-gssD1RJGKWxqRzfStwNraXA@mail.gmail.com>

Den fre 11 jan. 2019 kl 22:20 skrev Bill Lorensen <bill.lorensen at gmail.com>:
>
> There are over 1000 C++ examples. The web page for each example (and
> the associated tar file) is generated automatically for each example.
> To generate an example-specific components list for each example would
> be a challenge. For now, I'd rather modify the templates to include pf
> all the modules.
>
> When the entire collection of examples is built, either as a Remote
> module or stand-alone, it would be more of a challenge to handle the
> 1000 examples. I don't think it is worth the effort for what little
> would be gained.

Yes, you're probably right. But I don't think it would be that great
of a challenge? I mean, the WhatModulesVTK.py script sort of works
already (with a few kinks).

But no I agree, with that many examples, it would slow down the
generation time considerably, so probably not worth it.

Elvis

>
> On Fri, Jan 11, 2019 at 1:07 PM Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
> >
> > Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <ben.boeckel at kitware.com>:
> > >
> > > On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > > > I am surprised and amazed this works with the new system.
> > >
> > > I updated it since it was requested here. It also turned out to be quite
> > > helpful for determining real dependencies of things in ParaView and
> > > examples.
> >
> > Maybe some day in the future, with the enhancements you had in mind
> > (working with installed VTK et.c.), it could be robust enough to be
> > used when generating the CMakeLists.txt for the examples, so they
> > could show "best practice" and not linking all of VTK (cf Bill's
> > recent thread).
> >
> > Elvis
> >
> > >
> > > > When I wrote it, it:
> > > > 1) Only looked at the header files in your code and, from their name,
> > > > worked out the module to use. Ad a consequence of this we had to manually
> > > > include e.g. some modules like the OpenGL stuff.
> > >
> > > That's pretty much true still.
> > >
> > > > 2) Does detect modules excluded from the wrapping.
> > >
> > > Not hard now; it's still just a keyword in `vtk.module`. Though it
> > > doesn't do so right now.
> > >
> > > > 3) It was written before external modules were introduced so it may not
> > > > properly work with them.
> > >
> > > It only cares about `vtk.module` files (just like it cared only about
> > > `module.cmake` before. If it can find them in the path given, I don't
> > > think it should matter too much.
> > >
> > > > The intent was to provide to the user a guide as to what modules should be
> > > > included so they may still have to add extras.
> > >
> > > Yeah. I imagine the hard-coded if-then extensions were done because of
> > > this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> > > any module.
> > >
> > > --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://vtk.org/mailman/listinfo/vtk-developers
> >
>
>
> --
> Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Fri Jan 11 16:55:29 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 11 Jan 2019 16:55:29 -0500
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <CAE-7VJnam=Dfcuxxfh1Svbb01wa3ZZiM9k5Cvr3pomSADS37tA@mail.gmail.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
 <20190111210452.GB8874@rotor.localdomain>
 <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>
 <CAE-7VJmrzUMf0UcE6os9w+98SJ6Tir0A4dqf7MYURQ_4dDC2rQ@mail.gmail.com>
 <CAE-7VJnam=Dfcuxxfh1Svbb01wa3ZZiM9k5Cvr3pomSADS37tA@mail.gmail.com>
Message-ID: <20190111215529.GA17766@megas.kitware.com>

On Fri, Jan 11, 2019 at 22:39:21 +0100, Elvis Stansvik wrote:
> Den fre 11 jan. 2019 kl 22:33 skrev Elvis Stansvik
> > Hm, I realized I accidentally enabled testing when updating the flags.
> > When I corrected it to -DVTK_BUILD_TESTING=OFF, the CMake got much
> > further. Strange...

`VTK_BUILD_TESTING=ON` says "build all testing" and some module's tests
require IOParallel. But, IOParallel is gated by `VTK_USE_MPI` and
forcefully disabled without it, so it errors saying a required module
needs a module not allowed to build. There is also
`VTK_BUILD_TESTING=WANT` which builds as much testing as it can without
the disabled modules. In the long run, making these things
`TEST_OPTIONAL_DEPENDS` instead and skipping the relevant individual
tests is better.

> > Anyway, I'll probably get this working now.
> 
> The golden line for me:
> 
> cmake \
>     -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
>     -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
>     -DVTK_GROUP_ENABLE_Qt=YES \
>     -DVTK_GROUP_ENABLE_Imaging=YES \
>     -DVTK_GROUP_ENABLE_Views=YES \
>     -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
>     -DVTK_BUILD_TESTING=OFF \
>     -DVTK_USE_EXTERNAL=YES \
>     -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=OFF \
>     -DVTK_MODULE_USE_EXTERNAL_VTK_libharu=OFF \
>     -DCMAKE_BUILD_TYPE=None \
>     ../VTK
> 
> I had made a bunch of mistakes earlier. This line worked fine, and
> gl2ps and libharu were the only ones I needed to use the internal ones
> (due to slightly too old versions in Ubuntu 18.04).

These two are actually patched for API changes and have pending PRs for
them (mentioned in the CMake code), so upstream releases aren't ready
anyways.

--Ben

From elvis.stansvik at orexplore.com  Fri Jan 11 18:21:34 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 12 Jan 2019 00:21:34 +0100
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
Message-ID: <CAE-7VJmo=2bCVjBiARfjVxU5pZJ7T927Y_aZwvNeGdbmorgdOw@mail.gmail.com>

Den fre 11 jan. 2019 kl 20:01 skrev Bill Lorensen <bill.lorensen at gmail.com>:
>
> I like to see what modules might be excluded, etc. I'd like to see something.
>
> Is this the consensus?

I would also like something like that, perhaps something like this:
https://gist.github.com/estan/db8a9d5ea9e1354822484e9872204e96

Wouldn't have to be always on, but with an option.

I challenge anyone to write a printout like that in CMake :)

Elvis

>
> On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com wrote:
>>
>> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
>> > If the cache is rebuilt, I do not get and feedback. Just
>> > Configuring done
>> >
>> > How to get the feedback we used to get?
>>
>> What benefit did you derive from it? I always saw it as a wall of noise,
>> personally since it was unconditional and larger than a single screen
>> anyways.
>>
>> I guess, what output should we be generating? For each bit: Should it be
>> unconditional? If not, should it be on by default?
>>
>> --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://vtk.org/mailman/listinfo/vtk-developers
>

From elvis.stansvik at orexplore.com  Fri Jan 11 18:37:37 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 12 Jan 2019 00:37:37 +0100
Subject: [vtk-developers] CMake fails with build type "None" on Ubuntu
 18.04
In-Reply-To: <20190111215529.GA17766@megas.kitware.com>
References: <CAE-7VJnSpb844swiLgZLajXC8jYm-ozUPkLQke3TZ+XU2Mqq+w@mail.gmail.com>
 <20190111202843.GB23985@rotor.localdomain>
 <CAE-7VJ==Xi_ePBKv_nC1=drG4cjE4rhO5uBGjrDCv2c=xwyGZQ@mail.gmail.com>
 <20190111210452.GB8874@rotor.localdomain>
 <CAE-7VJkzVgChGRj8oaTErrdOT--OfFiO_9+YFVJQC=m8JkmOUg@mail.gmail.com>
 <CAE-7VJmrzUMf0UcE6os9w+98SJ6Tir0A4dqf7MYURQ_4dDC2rQ@mail.gmail.com>
 <CAE-7VJnam=Dfcuxxfh1Svbb01wa3ZZiM9k5Cvr3pomSADS37tA@mail.gmail.com>
 <20190111215529.GA17766@megas.kitware.com>
Message-ID: <CAE-7VJk+JCypob7Ru7XvhJXBS7eNVq_YAb0=RB9p_vUczr_jcw@mail.gmail.com>

Den fre 11 jan. 2019 kl 22:55 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Fri, Jan 11, 2019 at 22:39:21 +0100, Elvis Stansvik wrote:
> > Den fre 11 jan. 2019 kl 22:33 skrev Elvis Stansvik
> > > Hm, I realized I accidentally enabled testing when updating the flags.
> > > When I corrected it to -DVTK_BUILD_TESTING=OFF, the CMake got much
> > > further. Strange...
>
> `VTK_BUILD_TESTING=ON` says "build all testing" and some module's tests
> require IOParallel. But, IOParallel is gated by `VTK_USE_MPI` and
> forcefully disabled without it, so it errors saying a required module
> needs a module not allowed to build. There is also
> `VTK_BUILD_TESTING=WANT` which builds as much testing as it can without
> the disabled modules. In the long run, making these things
> `TEST_OPTIONAL_DEPENDS` instead and skipping the relevant individual
> tests is better.

Ah, thanks for the thorough clarification.

>
> > > Anyway, I'll probably get this working now.
> >
> > The golden line for me:
> >
> > cmake \
> >     -DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/VTK-inst \
> >     -DCMAKE_INSTALL_RPATH=/home/estan/orexplore/VTK-inst/lib \
> >     -DVTK_GROUP_ENABLE_Qt=YES \
> >     -DVTK_GROUP_ENABLE_Imaging=YES \
> >     -DVTK_GROUP_ENABLE_Views=YES \
> >     -DVTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig=YES \
> >     -DVTK_BUILD_TESTING=OFF \
> >     -DVTK_USE_EXTERNAL=YES \
> >     -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=OFF \
> >     -DVTK_MODULE_USE_EXTERNAL_VTK_libharu=OFF \
> >     -DCMAKE_BUILD_TYPE=None \
> >     ../VTK
> >
> > I had made a bunch of mistakes earlier. This line worked fine, and
> > gl2ps and libharu were the only ones I needed to use the internal ones
> > (due to slightly too old versions in Ubuntu 18.04).
>
> These two are actually patched for API changes and have pending PRs for
> them (mentioned in the CMake code), so upstream releases aren't ready
> anyways.

Ah, OK. Then I really am using as much from the system as I can :)

Elvis

>
> --Ben

From sean at rogue-research.com  Fri Jan 11 18:50:45 2019
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 11 Jan 2019 18:50:45 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
 <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
Message-ID: <20190111235045.1082849724@mail.rogue-research.com>

On Fri, 11 Jan 2019 15:04:21 -0500, Brad King said:

>It's likely CMake adding it based on Common/Core/CMakeLists.txt:
>
>```
>vtk_module_compile_features(VTK::CommonCore
>  PUBLIC
>    cxx_std_11
>    cxx_nullptr
>    cxx_override)
>```

So all this time I thought some of my bots were building as C++11, some C++14, some C++17, I have in fact been doing no such thing. :(

As a hack, I did a global replace of cxx_std_11 with cxx_std_14/17, and it turns out VTK 8.2 doesn't even build as either:

ThirdParty/lz4/vtklz4/lib/lz4.h:439:12: error: an attribute list cannot appear here
LZ4LIB_API LZ4_DEPRECATED("use LZ4_compress_default() instead") int LZ4_compress               (const char* source, char* dest, int sourceSize);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Filters/Core/vtkCellDataToPointData.cxx:85:31: error: no member named 'bind2nd' in namespace 'std'
                         std::bind2nd(std::divides<T>(), denom));
                         ~~~~~^

IO/XML/vtkXMLReader.cxx:1002:39: error: no member named 'ptr_fun' in namespace 'std'
                       std::not1(std::ptr_fun<int, int>(isspace))));
                                 ~~~~~^

Filters/FlowPaths/vtkTemporalStreamTracer.cxx:301:12: error: no member named 'bind2nd' in namespace 'std'
      std::bind2nd( WithinTolerance( ), requestedTimeValue ))
      ~~~~~^

Sean



From elvis.stansvik at orexplore.com  Fri Jan 11 18:56:58 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 12 Jan 2019 00:56:58 +0100
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <20190111201422.876359131@mail.rogue-research.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
 <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
 <20190111201422.876359131@mail.rogue-research.com>
Message-ID: <CAE-7VJ=NV1xb3rLJL1y92kGEg+Gk3WTS-WYWi896=3f+POcyMA@mail.gmail.com>

Den fre 11 jan. 2019 kl 21:14 skrev Sean McBride <sean at rogue-research.com>:
>
> On Fri, 11 Jan 2019 15:04:21 -0500, Brad King said:
>
> >On 1/11/19 2:59 PM, Sean McBride wrote:
> >> In cmake I set CMAKE_CXX_FLAGS to "-std=c++2a" but when I do "make
> >VERBOSE=1"
> >> I see that something is passing -std=c++11:
> >>
> >> Is this a bug?  If not, how do I specify the language variant?
> >
> >It's likely CMake adding it based on Common/Core/CMakeLists.txt:
> >
> >```
> >vtk_module_compile_features(VTK::CommonCore
> >  PUBLIC
> >    cxx_std_11
> >    cxx_nullptr
> >    cxx_override)
> >```
> >
> >There is an open CMake issue about handling future standards:
> >
> >  https://gitlab.kitware.com/cmake/cmake/issues/17146#note_300071
>
> It doesn't seem to matter that I've specified a 'future standard', even if I use -std=c++14 I get:
>
> cd /Users/sean/external/VTK-8bin/Utilities/KWIML/vtkkwiml/test && /Users/sean/llvm/llvm-rel-install/bin/clang++  -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -DVTK_IN_VTK -I/Users/sean/external/VTK-8bin/Utilities/KWIML -I/Users/sean/external/VTK/Utilities/KWIML  -std=c++14  -g   -std=c++11 -o CMakeFiles/kwiml_test.dir/test_include_CXX.cxx.o -c /Users/sean/external/VTK/Utilities/KWIML/vtkkwiml/test/test_include_CXX.cx,

Just a wild guess, try -DCMAKE_CXX_STANDARD=14 instead of
-DCMAKE_CXX_FLAGS="-std=c++14"? Maybe CMake will consider
CMAKE_CXX_STANDARD=14 as having the cxx_std_11 compile feature and not
"downgrade" you?

Elvis

>
> Sean
>
>
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>

From bill.lorensen at gmail.com  Fri Jan 11 19:17:15 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 11 Jan 2019 16:17:15 -0800
Subject: [vtk-developers] Lack of feedback during cache building
In-Reply-To: <CAE-7VJmo=2bCVjBiARfjVxU5pZJ7T927Y_aZwvNeGdbmorgdOw@mail.gmail.com>
References: <CADZJ4hPi6H5o0afcRjiTrX6YZVBz86JGbCJ4T0W8ZSR3_uo5_g@mail.gmail.com>
 <20190111185411.GA22858@megas.kitware.com>
 <CADZJ4hO0UUBYye_3grdFQfvVwZ9ABaPR27phA0=oERju9yW9mw@mail.gmail.com>
 <CAE-7VJmo=2bCVjBiARfjVxU5pZJ7T927Y_aZwvNeGdbmorgdOw@mail.gmail.com>
Message-ID: <CADZJ4hNw24dhnCbwA54JDL6Z9x4hubgrXbJz5igLbM1jZAQL9A@mail.gmail.com>

How about redirecting the old output to a file called status.log or
something. And a visible feedback that says "See status.log for information
on the config process." Or something like that. You me, the old format was
fine.

On Fri, Jan 11, 2019, 3:21 PM Elvis Stansvik <elvis.stansvik at orexplore.com
wrote:

> Den fre 11 jan. 2019 kl 20:01 skrev Bill Lorensen <bill.lorensen at gmail.com
> >:
> >
> > I like to see what modules might be excluded, etc. I'd like to see
> something.
> >
> > Is this the consensus?
>
> I would also like something like that, perhaps something like this:
> https://gist.github.com/estan/db8a9d5ea9e1354822484e9872204e96
>
> Wouldn't have to be always on, but with an option.
>
> I challenge anyone to write a printout like that in CMake :)
>
> Elvis
>
> >
> > On Fri, Jan 11, 2019, 10:54 AM Ben Boeckel <ben.boeckel at kitware.com
> wrote:
> >>
> >> On Fri, Jan 11, 2019 at 10:31:32 -0800, Bill Lorensen wrote:
> >> > If the cache is rebuilt, I do not get and feedback. Just
> >> > Configuring done
> >> >
> >> > How to get the feedback we used to get?
> >>
> >> What benefit did you derive from it? I always saw it as a wall of noise,
> >> personally since it was unconditional and larger than a single screen
> >> anyways.
> >>
> >> I guess, what output should we be generating? For each bit: Should it be
> >> unconditional? If not, should it be on by default?
> >>
> >> --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://vtk.org/mailman/listinfo/vtk-developers
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/72d8b774/attachment.html>

From andrew.amaclean at gmail.com  Sat Jan 12 01:22:30 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 12 Jan 2019 17:22:30 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
Message-ID: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>

In summary, I get a build on Ubuntu 18.10 with just the defaults and these
changes:
VTK_ENABLE_GROUP_QT->WANT
VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
VTK_WRAP_PYTHON on
VTK_PYTHON_VERSION 3
VTK_SMP_IMPLEMENTATION_TYPE TBB

In VTK/lib there is a python2.7 folder. Given that I built for Python
3.7.1, is this folder name correct?

Of concern is the UUID error and the fact Java wrapping seems to be broken,
see comments below.

With the old version of VTK, I built FreeType ok, Java wrapping worked and
there was no UUID error.


I have local installations of Java 11.0.1, Anaconda Python 3.7.1 and TBB.
    Cmake found the Anaconda Python release library Ok, Java Ok, TBB Ok.
    Set Java source/target versions to 1.9 (The wrapping doesn't know about
version 1.11)

1) Using TBB
   CMake Found libtbb_debug.so, libtbb.so however had to set
libtbb_debug.so.2, libtbb.so.2 instead.

2) FAILED: bin/vtkRenderingFreeTypeCxxTests
    Error:
    usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
`uuid_unparse_lower at UUID_1.0'
    /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
`uuid_generate at UUID_1.0'

    So I installed the package uuid-dev

    However the same error occurred.


    So I set: VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO

3) Java Wrapping (Using Java 11)

    It failed compiling Java classes:
    Lots of errors like this:

/home/amaclean/Development/Kitware/build/VTK/Wrapping/Java/src/vtk/rendering/vtkAbstractComponent.java:5:
error: cannot find symbol
    import vtk.vtkAxesActor;
              ^
      symbol:   class vtkAxesActor
      location: package vtk

/home/amaclean/Development/Kitware/build/VTK/Wrapping/Java/src/vtk/rendering/vtkAbstractComponent.java:10:
error: cannot find symbol
    import vtk.vtkOrientationMarkerWidget;
              ^
      symbol:   class vtkOrientationMarkerWidget
      location: package vtk

      So I turned off Java Wrapping

4) Build successful.
5) Tests:
    98% tests passed, 15 tests failed out of 801

    Total Test time (real) = 194.78 sec

    The following tests FAILED:
            201 - VTK::IOGeometryPython-Plot3DVectors (Failed)
            301 - VTK::FiltersHybridPython-3DMorph (Failed)
            303 - VTK::FiltersHybridPython-TestGridWarp3D (Failed)
            304 - VTK::FiltersHybridPython-TestGridWarpCubic (Failed)
            305 - VTK::FiltersHybridPython-TestGridWarpLinear (Failed)
            306 - VTK::FiltersHybridPython-TestGridWarpNearest (Failed)
            307 - VTK::FiltersHybridPython-TestImageStencilWithPolydata
(Failed)
            319 - VTK::FiltersHybridPython-largeImageGradientBackground
(Failed)
            320 - VTK::FiltersHybridPython-largeImageOffset (Failed)
            321 - VTK::FiltersHybridPython-largeImageParallel (Failed)
            383 - VTK::FiltersModelingPython-HyperScalarBar (Failed)
            387 - VTK::FiltersModelingPython-TestBandedContourFilter
(Failed)
            406 - VTK::FiltersModelingPython-extrudeCopyCD (Failed)
            550 -
VTK::CommonComputationalGeometryPython-TestParametricFunctions (Failed)
            551 -
VTK::CommonComputationalGeometryPython-TestMoreParametricFunctions (Failed)
    Errors while running CTest

6) VTK Python all good:

    Python 3.7.1 (default, Dec 14 2018, 19:33:21)
    [GCC 7.3.0] :: Anaconda, Inc. on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

7) No Qt built so set VTK_ENABLE_GROUP_QT->WANT

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/a7a86188/attachment.html>

From dan.lipsa at kitware.com  Sat Jan 12 10:04:27 2019
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Sat, 12 Jan 2019 10:04:27 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
Message-ID: <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>

On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> In summary, I get a build on Ubuntu 18.10 with just the defaults and these
> changes:
> VTK_ENABLE_GROUP_QT->WANT
> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
> VTK_WRAP_PYTHON on
> VTK_PYTHON_VERSION 3
> VTK_SMP_IMPLEMENTATION_TYPE TBB
>
> In VTK/lib there is a python2.7 folder. Given that I built for Python
> 3.7.1, is this folder name correct?
>

I've seen the same behavior. For some reason
PYTHON_EXECUTABLE:FILEPATH
points to the python2 executable instead of python3.
A workaround is to change it to point to the correct python and that fixes
the problem.
I have not looked into why the variable is set this way.

Dan


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190112/491621af/attachment.html>

From andrew.amaclean at gmail.com  Sat Jan 12 16:39:51 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 13 Jan 2019 08:39:51 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
Message-ID: <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>

Thanks for that advice.
FYI: The PYTHON_EXECUTABLE:FILEPATH is in Ungrouped Entries.

Regards
   Andrew

On Sun, Jan 13, 2019 at 2:05 AM Dan Lipsa <dan.lipsa at kitware.com> wrote:

>
>
> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <andrew.amaclean at gmail.com>
> wrote:
>
>> In summary, I get a build on Ubuntu 18.10 with just the defaults and
>> these changes:
>> VTK_ENABLE_GROUP_QT->WANT
>> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
>> VTK_WRAP_PYTHON on
>> VTK_PYTHON_VERSION 3
>> VTK_SMP_IMPLEMENTATION_TYPE TBB
>>
>> In VTK/lib there is a python2.7 folder. Given that I built for Python
>> 3.7.1, is this folder name correct?
>>
>
> I've seen the same behavior. For some reason
> PYTHON_EXECUTABLE:FILEPATH
> points to the python2 executable instead of python3.
> A workaround is to change it to point to the correct python and that fixes
> the problem.
> I have not looked into why the variable is set this way.
>
> Dan
>
>
>>

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190113/053c1c51/attachment.html>

From andrew.amaclean at gmail.com  Sat Jan 12 18:03:58 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 13 Jan 2019 10:03:58 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
Message-ID: <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>

Also fixed the errors:
    usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
`uuid_unparse_lower at UUID_1.0'
    /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
`uuid_generate at UUID_1.0'

by adding -luuid to CMAKE_CXX_FLAGS

Regards
   Andrew


On Sun, Jan 13, 2019 at 8:39 AM Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Thanks for that advice.
> FYI: The PYTHON_EXECUTABLE:FILEPATH is in Ungrouped Entries.
>
> Regards
>    Andrew
>
> On Sun, Jan 13, 2019 at 2:05 AM Dan Lipsa <dan.lipsa at kitware.com> wrote:
>
>>
>>
>> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <andrew.amaclean at gmail.com>
>> wrote:
>>
>>> In summary, I get a build on Ubuntu 18.10 with just the defaults and
>>> these changes:
>>> VTK_ENABLE_GROUP_QT->WANT
>>> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
>>> VTK_WRAP_PYTHON on
>>> VTK_PYTHON_VERSION 3
>>> VTK_SMP_IMPLEMENTATION_TYPE TBB
>>>
>>> In VTK/lib there is a python2.7 folder. Given that I built for Python
>>> 3.7.1, is this folder name correct?
>>>
>>
>> I've seen the same behavior. For some reason
>> PYTHON_EXECUTABLE:FILEPATH
>> points to the python2 executable instead of python3.
>> A workaround is to change it to point to the correct python and that
>> fixes the problem.
>> I have not looked into why the variable is set this way.
>>
>> Dan
>>
>>
>>>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190113/c6f74251/attachment.html>

From andrew.amaclean at gmail.com  Sat Jan 12 20:28:15 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 13 Jan 2019 12:28:15 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
Message-ID: <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>

Ben what you have done is outstanding!!!! +1

Ok on Ubuntu 18.10 I get a clean build now with these conditions.

I have local installations of Java 11.0.1, Anaconda Python 3.7.1 and TBB.
CMake found the Anaconda Python release library Ok, Java Ok, TBB Ok

Building with just the defaults and these changes:

VTK_ALL_NEW_OBJECT_FACTORY ON
VTK_ENABLE_GROUP_QT                WANT
VTK_JAVA_SOURCE_VERSION         1.9
VTK_JAVA_TARGET_VERSION          1.9
VTK_WRAP_PYTHON                          ON
VTK_PYTHON_VERSION                     3
VTK_SMP_IMPLEMTATION_TYPE      TBB
VTK_WRAP_JAVA                                 ON
VTK_WRAP_PYTHON                          ON

Then:
1) Manually set PYTHON_EXECUTABLE to
/home/<user_name>/anaconda3/bin/python3.7m
     Note: This is found in Ungrouped Entries
2) Set Java source/target versions to 1.9 (The wrapping doesn't know about
version 1.11)
3) TBB:
   In TBB_LIBRARY_DEBUG change libtbb_debug.so to libtbb_debug.so.2.
   In TBB_LIBRARY_RELEASE change libtbb.so to libtbb.so.2.
4) Add -luuid to CMAKE_CXX_FLAGS

Final result:
99% tests passed, 1 tests failed out of 2010

The following tests FAILED:
        293 - VTK::IOExportPDFCxx-TestPDFTransformedText (Failed)
Errors while running CTest

vtkpython works:
Python 3.7.1 (default, Dec 14 2018, 19:33:21)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

Regards
   Andrew

On Sun, Jan 13, 2019 at 10:03 AM Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Also fixed the errors:
>     usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
> `uuid_unparse_lower at UUID_1.0'
>     /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference
> to `uuid_generate at UUID_1.0'
>
> by adding -luuid to CMAKE_CXX_FLAGS
>
> Regards
>    Andrew
>
>
> On Sun, Jan 13, 2019 at 8:39 AM Andrew Maclean <andrew.amaclean at gmail.com>
> wrote:
>
>> Thanks for that advice.
>> FYI: The PYTHON_EXECUTABLE:FILEPATH is in Ungrouped Entries.
>>
>> Regards
>>    Andrew
>>
>> On Sun, Jan 13, 2019 at 2:05 AM Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <
>>> andrew.amaclean at gmail.com> wrote:
>>>
>>>> In summary, I get a build on Ubuntu 18.10 with just the defaults and
>>>> these changes:
>>>> VTK_ENABLE_GROUP_QT->WANT
>>>> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
>>>> VTK_WRAP_PYTHON on
>>>> VTK_PYTHON_VERSION 3
>>>> VTK_SMP_IMPLEMENTATION_TYPE TBB
>>>>
>>>> In VTK/lib there is a python2.7 folder. Given that I built for Python
>>>> 3.7.1, is this folder name correct?
>>>>
>>>
>>> I've seen the same behavior. For some reason
>>> PYTHON_EXECUTABLE:FILEPATH
>>> points to the python2 executable instead of python3.
>>> A workaround is to change it to point to the correct python and that
>>> fixes the problem.
>>> I have not looked into why the variable is set this way.
>>>
>>> Dan
>>>
>>>
>>>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>> ___________________________________________
>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190113/eeff3dac/attachment-0001.html>

From elvis.stansvik at orexplore.com  Sun Jan 13 05:32:34 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 13 Jan 2019 11:32:34 +0100
Subject: [vtk-developers] Using VTK master fails on Ubuntu 18.04 due to
 missing FindPython3.cmake
Message-ID: <CAE-7VJnVQvDJBVAMykxRy+Z_8H85nD1xodK2SmHfjAUpGq9hYA@mail.gmail.com>

Trying to build a project against VTK master on Ubuntu 18.04, I get:

CMake Error at /home/estan/orexplore/VTK-inst/lib/cmake/vtk-8.90/VTK-vtk-module-find-packages.cmake:475
(find_package):
  By not providing "FindPython3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Python3", but
  CMake did not find one.

  Could not find a package configuration file provided by "Python3"
  (requested version 3.6) with any of the following names:

    Python3Config.cmake
    python3-config.cmake

  Add the installation prefix of "Python3" to CMAKE_PREFIX_PATH or set
  "Python3_DIR" to a directory containing one of the above files.  If
  "Python3" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/estan/orexplore/VTK-inst/lib/cmake/vtk-8.90/vtk-config.cmake:92
(include)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!

The new FindPython3.cmake was added in CMake 3.12, but Ubuntu 18.04
has CMake 3.10.2.

I know building VTK itself is possible with CMake 3.8+ (this VTK was
built on the same machine).

Should perhaps the installed VTK-vtk-module-find-packages.cmake be
updated so that it can work with the older Python-finding stuff as
well?

Elvis

From elvis.stansvik at orexplore.com  Sun Jan 13 05:34:24 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 13 Jan 2019 11:34:24 +0100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
Message-ID: <CAE-7VJnD8eFbR-oEWFfAfer7azONLOMXZksbmXw7d3aaAHVOwg@mail.gmail.com>

Den s?n 13 jan. 2019 kl 02:28 skrev Andrew Maclean <andrew.amaclean at gmail.com>:
>
> Ben what you have done is outstanding!!!! +1

+1 This is fantastic work, monumental. And CMake step when building
VTK is so much faster.

Elvis

>
> Ok on Ubuntu 18.10 I get a clean build now with these conditions.
>
> I have local installations of Java 11.0.1, Anaconda Python 3.7.1 and TBB.
> CMake found the Anaconda Python release library Ok, Java Ok, TBB Ok
>
> Building with just the defaults and these changes:
>
> VTK_ALL_NEW_OBJECT_FACTORY ON
> VTK_ENABLE_GROUP_QT                WANT
> VTK_JAVA_SOURCE_VERSION         1.9
> VTK_JAVA_TARGET_VERSION          1.9
> VTK_WRAP_PYTHON                          ON
> VTK_PYTHON_VERSION                     3
> VTK_SMP_IMPLEMTATION_TYPE      TBB
> VTK_WRAP_JAVA                                 ON
> VTK_WRAP_PYTHON                          ON
>
> Then:
> 1) Manually set PYTHON_EXECUTABLE to /home/<user_name>/anaconda3/bin/python3.7m
>      Note: This is found in Ungrouped Entries
> 2) Set Java source/target versions to 1.9 (The wrapping doesn't know about version 1.11)
> 3) TBB:
>    In TBB_LIBRARY_DEBUG change libtbb_debug.so to libtbb_debug.so.2.
>    In TBB_LIBRARY_RELEASE change libtbb.so to libtbb.so.2.
> 4) Add -luuid to CMAKE_CXX_FLAGS
>
> Final result:
> 99% tests passed, 1 tests failed out of 2010
>
> The following tests FAILED:
>         293 - VTK::IOExportPDFCxx-TestPDFTransformedText (Failed)
> Errors while running CTest
>
> vtkpython works:
> Python 3.7.1 (default, Dec 14 2018, 19:33:21)
> [GCC 7.3.0] :: Anaconda, Inc. on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> exit()
>
> Regards
>    Andrew
>
> On Sun, Jan 13, 2019 at 10:03 AM Andrew Maclean <andrew.amaclean at gmail.com> wrote:
>>
>> Also fixed the errors:
>>     usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to `uuid_unparse_lower at UUID_1.0'
>>     /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to `uuid_generate at UUID_1.0'
>>
>> by adding -luuid to CMAKE_CXX_FLAGS
>>
>> Regards
>>    Andrew
>>
>>
>> On Sun, Jan 13, 2019 at 8:39 AM Andrew Maclean <andrew.amaclean at gmail.com> wrote:
>>>
>>> Thanks for that advice.
>>> FYI: The PYTHON_EXECUTABLE:FILEPATH is in Ungrouped Entries.
>>>
>>> Regards
>>>    Andrew
>>>
>>> On Sun, Jan 13, 2019 at 2:05 AM Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <andrew.amaclean at gmail.com> wrote:
>>>>>
>>>>> In summary, I get a build on Ubuntu 18.10 with just the defaults and these changes:
>>>>> VTK_ENABLE_GROUP_QT->WANT
>>>>> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
>>>>> VTK_WRAP_PYTHON on
>>>>> VTK_PYTHON_VERSION 3
>>>>> VTK_SMP_IMPLEMENTATION_TYPE TBB
>>>>>
>>>>> In VTK/lib there is a python2.7 folder. Given that I built for Python 3.7.1, is this folder name correct?
>>>>
>>>>
>>>> I've seen the same behavior. For some reason
>>>> PYTHON_EXECUTABLE:FILEPATH
>>>> points to the python2 executable instead of python3.
>>>> A workaround is to change it to point to the correct python and that fixes the problem.
>>>> I have not looked into why the variable is set this way.
>>>>
>>>> Dan
>>>>
>>>>>
>>>
>>>
>>> --
>>> ___________________________________________
>>> Andrew J. P. Maclean
>>>
>>> ___________________________________________
>>
>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>> ___________________________________________
>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>

From elvis.stansvik at orexplore.com  Sun Jan 13 06:12:48 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 13 Jan 2019 12:12:48 +0100
Subject: [vtk-developers] Using VTK master fails on Ubuntu 18.04 due to
 missing FindPython3.cmake
In-Reply-To: <CAE-7VJnVQvDJBVAMykxRy+Z_8H85nD1xodK2SmHfjAUpGq9hYA@mail.gmail.com>
References: <CAE-7VJnVQvDJBVAMykxRy+Z_8H85nD1xodK2SmHfjAUpGq9hYA@mail.gmail.com>
Message-ID: <CAE-7VJ==HTKkRUmHxL58f_BbLw5wqAySbM5Hc4mHJtG+534LdA@mail.gmail.com>

Den s?n 13 jan. 2019 kl 11:32 skrev Elvis Stansvik
<elvis.stansvik at orexplore.com>:
>
> Trying to build a project against VTK master on Ubuntu 18.04, I get:
>
> CMake Error at /home/estan/orexplore/VTK-inst/lib/cmake/vtk-8.90/VTK-vtk-module-find-packages.cmake:475
> (find_package):
>   By not providing "FindPython3.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "Python3", but
>   CMake did not find one.
>
>   Could not find a package configuration file provided by "Python3"
>   (requested version 3.6) with any of the following names:
>
>     Python3Config.cmake
>     python3-config.cmake
>
>   Add the installation prefix of "Python3" to CMAKE_PREFIX_PATH or set
>   "Python3_DIR" to a directory containing one of the above files.  If
>   "Python3" provides a separate development package or SDK, be sure it has
>   been installed.
> Call Stack (most recent call first):
>   /home/estan/orexplore/VTK-inst/lib/cmake/vtk-8.90/vtk-config.cmake:92
> (include)
>   CMakeLists.txt:5 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
>
> The new FindPython3.cmake was added in CMake 3.12, but Ubuntu 18.04
> has CMake 3.10.2.
>
> I know building VTK itself is possible with CMake 3.8+ (this VTK was
> built on the same machine).
>
> Should perhaps the installed VTK-vtk-module-find-packages.cmake be
> updated so that it can work with the older Python-finding stuff as
> well?

Nevermind, I realized it was just a matter of making sure
CMake/patches/3.13/FindPython* is installed, to maintain
compatibility.

Ben: I made an MR for this:
https://gitlab.kitware.com/vtk/vtk/merge_requests/5059

Elvis


>
> Elvis

From andrew.amaclean at gmail.com  Sun Jan 13 23:43:00 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 14 Jan 2019 15:43:00 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAE-7VJnD8eFbR-oEWFfAfer7azONLOMXZksbmXw7d3aaAHVOwg@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
 <CAE-7VJnD8eFbR-oEWFfAfer7azONLOMXZksbmXw7d3aaAHVOwg@mail.gmail.com>
Message-ID: <CAHDsG9OXdyT1G7QE7+C_Mzn_QnHPXyKdWkJrGghKBjW32t=uFg@mail.gmail.com>

Currently Java wrapping fails in Windows.

On Sun, Jan 13, 2019 at 9:34 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> Den s?n 13 jan. 2019 kl 02:28 skrev Andrew Maclean <
> andrew.amaclean at gmail.com>:
> >
> > Ben what you have done is outstanding!!!! +1
>
> +1 This is fantastic work, monumental. And CMake step when building
> VTK is so much faster.
>
> Elvis
>
> >
> > Ok on Ubuntu 18.10 I get a clean build now with these conditions.
> >
> > I have local installations of Java 11.0.1, Anaconda Python 3.7.1 and TBB.
> > CMake found the Anaconda Python release library Ok, Java Ok, TBB Ok
> >
> > Building with just the defaults and these changes:
> >
> > VTK_ALL_NEW_OBJECT_FACTORY ON
> > VTK_ENABLE_GROUP_QT                WANT
> > VTK_JAVA_SOURCE_VERSION         1.9
> > VTK_JAVA_TARGET_VERSION          1.9
> > VTK_WRAP_PYTHON                          ON
> > VTK_PYTHON_VERSION                     3
> > VTK_SMP_IMPLEMTATION_TYPE      TBB
> > VTK_WRAP_JAVA                                 ON
> > VTK_WRAP_PYTHON                          ON
> >
> > Then:
> > 1) Manually set PYTHON_EXECUTABLE to
> /home/<user_name>/anaconda3/bin/python3.7m
> >      Note: This is found in Ungrouped Entries
> > 2) Set Java source/target versions to 1.9 (The wrapping doesn't know
> about version 1.11)
> > 3) TBB:
> >    In TBB_LIBRARY_DEBUG change libtbb_debug.so to libtbb_debug.so.2.
> >    In TBB_LIBRARY_RELEASE change libtbb.so to libtbb.so.2.
> > 4) Add -luuid to CMAKE_CXX_FLAGS
> >
> > Final result:
> > 99% tests passed, 1 tests failed out of 2010
> >
> > The following tests FAILED:
> >         293 - VTK::IOExportPDFCxx-TestPDFTransformedText (Failed)
> > Errors while running CTest
> >
> > vtkpython works:
> > Python 3.7.1 (default, Dec 14 2018, 19:33:21)
> > [GCC 7.3.0] :: Anaconda, Inc. on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> exit()
> >
> > Regards
> >    Andrew
> >
> > On Sun, Jan 13, 2019 at 10:03 AM Andrew Maclean <
> andrew.amaclean at gmail.com> wrote:
> >>
> >> Also fixed the errors:
> >>     usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference
> to `uuid_unparse_lower at UUID_1.0'
> >>     /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined
> reference to `uuid_generate at UUID_1.0'
> >>
> >> by adding -luuid to CMAKE_CXX_FLAGS
> >>
> >> Regards
> >>    Andrew
> >>
> >>
> >> On Sun, Jan 13, 2019 at 8:39 AM Andrew Maclean <
> andrew.amaclean at gmail.com> wrote:
> >>>
> >>> Thanks for that advice.
> >>> FYI: The PYTHON_EXECUTABLE:FILEPATH is in Ungrouped Entries.
> >>>
> >>> Regards
> >>>    Andrew
> >>>
> >>> On Sun, Jan 13, 2019 at 2:05 AM Dan Lipsa <dan.lipsa at kitware.com>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <
> andrew.amaclean at gmail.com> wrote:
> >>>>>
> >>>>> In summary, I get a build on Ubuntu 18.10 with just the defaults and
> these changes:
> >>>>> VTK_ENABLE_GROUP_QT->WANT
> >>>>> VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
> >>>>> VTK_WRAP_PYTHON on
> >>>>> VTK_PYTHON_VERSION 3
> >>>>> VTK_SMP_IMPLEMENTATION_TYPE TBB
> >>>>>
> >>>>> In VTK/lib there is a python2.7 folder. Given that I built for
> Python 3.7.1, is this folder name correct?
> >>>>
> >>>>
> >>>> I've seen the same behavior. For some reason
> >>>> PYTHON_EXECUTABLE:FILEPATH
> >>>> points to the python2 executable instead of python3.
> >>>> A workaround is to change it to point to the correct python and that
> fixes the problem.
> >>>> I have not looked into why the variable is set this way.
> >>>>
> >>>> Dan
> >>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> ___________________________________________
> >>> Andrew J. P. Maclean
> >>>
> >>> ___________________________________________
> >>
> >>
> >>
> >> --
> >> ___________________________________________
> >> Andrew J. P. Maclean
> >>
> >> ___________________________________________
> >
> >
> >
> > --
> > ___________________________________________
> > Andrew J. P. Maclean
> >
> > ___________________________________________
> > _______________________________________________
> > 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://vtk.org/mailman/listinfo/vtk-developers
> >
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190114/43c23bed/attachment.html>

From brad.king at kitware.com  Mon Jan 14 06:36:08 2019
From: brad.king at kitware.com (Brad King)
Date: Mon, 14 Jan 2019 06:36:08 -0500
Subject: [vtk-developers] VTK forces -std=c++11 ?
In-Reply-To: <CAE-7VJ=NV1xb3rLJL1y92kGEg+Gk3WTS-WYWi896=3f+POcyMA@mail.gmail.com>
References: <20190111195923.2117407654@mail.rogue-research.com>
 <f63cd9a6-2814-bf74-3359-8e225c6025b7@kitware.com>
 <20190111201422.876359131@mail.rogue-research.com>
 <CAE-7VJ=NV1xb3rLJL1y92kGEg+Gk3WTS-WYWi896=3f+POcyMA@mail.gmail.com>
Message-ID: <ffc4f022-5f89-4b6f-7a7d-9c9a759d2f63@kitware.com>

On 1/11/19 6:56 PM, Elvis Stansvik wrote:
> Just a wild guess, try -DCMAKE_CXX_STANDARD=14 instead of
> -DCMAKE_CXX_FLAGS="-std=c++14"? Maybe CMake will consider
> CMAKE_CXX_STANDARD=14 as having the cxx_std_11 compile feature and not
> "downgrade" you?

Yes, that is the intended way.  I should have mentioned it.
The CMake issue I linked is about support for standards that
CMake does not yet know about, but CMake already has C++20.

-Brad

From ben.boeckel at kitware.com  Mon Jan 14 10:24:02 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 14 Jan 2019 10:24:02 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9OXdyT1G7QE7+C_Mzn_QnHPXyKdWkJrGghKBjW32t=uFg@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
 <CAE-7VJnD8eFbR-oEWFfAfer7azONLOMXZksbmXw7d3aaAHVOwg@mail.gmail.com>
 <CAHDsG9OXdyT1G7QE7+C_Mzn_QnHPXyKdWkJrGghKBjW32t=uFg@mail.gmail.com>
Message-ID: <20190114152402.GD19915@megas.kitware.com>

On Mon, Jan 14, 2019 at 15:43:00 +1100, Andrew Maclean wrote:
> Currently Java wrapping fails in Windows.

Could you please open an issue with details? I'll have to get Java
installed on a Windows machine here to dig into it myself.

Thanks.

--Ben

From ben.boeckel at kitware.com  Mon Jan 14 10:25:29 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 14 Jan 2019 10:25:29 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
Message-ID: <20190114152529.GE19915@megas.kitware.com>

On Sat, Jan 12, 2019 at 10:04:27 -0500, Dan Lipsa via vtk-developers wrote:
> On Sat, Jan 12, 2019 at 1:23 AM Andrew Maclean <andrew.amaclean at gmail.com>
> wrote:
> 
> > In summary, I get a build on Ubuntu 18.10 with just the defaults and these
> > changes:
> > VTK_ENABLE_GROUP_QT->WANT
> > VTK_MODULE_ENABLE_VTK_RenderingFreeType DEFAULT->NO
> > VTK_WRAP_PYTHON on
> > VTK_PYTHON_VERSION 3
> > VTK_SMP_IMPLEMENTATION_TYPE TBB
> >
> > In VTK/lib there is a python2.7 folder. Given that I built for Python
> > 3.7.1, is this folder name correct?
> >
> 
> I've seen the same behavior. For some reason
> PYTHON_EXECUTABLE:FILEPATH
> points to the python2 executable instead of python3.
> A workaround is to change it to point to the correct python and that fixes
> the problem.
> I have not looked into why the variable is set this way.

I think it has to do with `VTK_PYTHON_VERSION` defaulting to 2, finding
that, then when switched to 3, it says "oh, we already have one" and not
re-finding it. I thought the `FindPython2` and `FindPython3` split was
supposed to fix this, but I guess I missed something somewhere. Some
CMake tracing/debugging will be necessary.

--Ben

From ben.boeckel at kitware.com  Mon Jan 14 10:27:49 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 14 Jan 2019 10:27:49 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
Message-ID: <20190114152749.GF19915@megas.kitware.com>

On Sun, Jan 13, 2019 at 10:03:58 +1100, Andrew Maclean wrote:
> Also fixed the errors:
>     usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
> `uuid_unparse_lower at UUID_1.0'
>     /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
> `uuid_generate at UUID_1.0'
> 
> by adding -luuid to CMAKE_CXX_FLAGS

This, IMO, is a FindPython issue. CMake issue filed here:

    https://gitlab.kitware.com/cmake/cmake/issues/18798

Once it is fixed, we should backport it into VTK (and move it from the
3.13 directory to 3.14 or 3.15 depending on when it gets merged).

--Ben

From ben.boeckel at kitware.com  Mon Jan 14 10:30:53 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 14 Jan 2019 10:30:53 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
Message-ID: <20190114153053.GG19915@megas.kitware.com>

On Sun, Jan 13, 2019 at 12:28:15 +1100, Andrew Maclean wrote:
> Ben what you have done is outstanding!!!! +1

Thanks :) .

> 1) Manually set PYTHON_EXECUTABLE to
> /home/<user_name>/anaconda3/bin/python3.7m
>      Note: This is found in Ungrouped Entries

Hmm, this indicates that it is probably going through `FindPython`
rather than a versioned variant. I wonder if `VTK_PYTHON_VERSION` is
unset or unused in one place. It's ungrouped since cmake-gui groups
based on the part before the first `_`.

> 2) Set Java source/target versions to 1.9 (The wrapping doesn't know about
> version 1.11)

Hmm, interesting. What should be done here? Should we just copy the
version down from the Java CMake finds? I'm not that familiar with Java.

> 3) TBB:
>    In TBB_LIBRARY_DEBUG change libtbb_debug.so to libtbb_debug.so.2.
>    In TBB_LIBRARY_RELEASE change libtbb.so to libtbb.so.2.

Why does this need to be done? Is this something to do with these being
linker scripts?

> 4) Add -luuid to CMAKE_CXX_FLAGS

See previous email.

> Final result:
> 99% tests passed, 1 tests failed out of 2010
> 
> The following tests FAILED:
>         293 - VTK::IOExportPDFCxx-TestPDFTransformedText (Failed)
> Errors while running CTest

Yeah, dashboards are having issues here too.

--Ben

From ben.boeckel at kitware.com  Mon Jan 14 10:46:49 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 14 Jan 2019 10:46:49 -0500
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <20190114152749.GF19915@megas.kitware.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <20190114152749.GF19915@megas.kitware.com>
Message-ID: <20190114154649.GK19915@megas.kitware.com>

On Mon, Jan 14, 2019 at 10:27:49 -0500, Ben Boeckel wrote:
> On Sun, Jan 13, 2019 at 10:03:58 +1100, Andrew Maclean wrote:
> > Also fixed the errors:
> >     usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
> > `uuid_unparse_lower at UUID_1.0'
> >     /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libSM.so: undefined reference to
> > `uuid_generate at UUID_1.0'
> > 
> > by adding -luuid to CMAKE_CXX_FLAGS
> 
> This, IMO, is a FindPython issue. CMake issue filed here:
> 
>     https://gitlab.kitware.com/cmake/cmake/issues/18798
> 
> Once it is fixed, we should backport it into VTK (and move it from the
> 3.13 directory to 3.14 or 3.15 depending on when it gets merged).

D'oh. I missed the `libSM` part. This is a FindX11 bug. I'll try to have
a fix this week.

--Ben

From andrew.amaclean at gmail.com  Mon Jan 14 23:42:39 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Tue, 15 Jan 2019 15:42:39 +1100
Subject: [vtk-developers] Building VTK Master (8.90)
In-Reply-To: <20190114152402.GD19915@megas.kitware.com>
References: <CAHDsG9MRW+RiXajN7eVyXDGLa8HjT+QDw+xT3U+3GNnet4T=9Q@mail.gmail.com>
 <CADwGrVr-bwuXr7no538r+YO=JHdWkoKUA98G4Q4p9D4DDY8Pyw@mail.gmail.com>
 <CAHDsG9Pwe1qisGwzPGUsThiw+vHv7YCT3yAL_+Hfx_6gMqKF1g@mail.gmail.com>
 <CAHDsG9P0QG-jGBR3rV+6+zCEQqt7_UpDCseci2EbqN5DqFwCcg@mail.gmail.com>
 <CAHDsG9NuUYgaNPPM6tz2sov+Xue9TiUEJETtUm26o18tANrpJQ@mail.gmail.com>
 <CAE-7VJnD8eFbR-oEWFfAfer7azONLOMXZksbmXw7d3aaAHVOwg@mail.gmail.com>
 <CAHDsG9OXdyT1G7QE7+C_Mzn_QnHPXyKdWkJrGghKBjW32t=uFg@mail.gmail.com>
 <20190114152402.GD19915@megas.kitware.com>
Message-ID: <CAHDsG9PTEER1MkNejSSMrdCuWVumnyOi1n-1fv0YX2LoXmAwGQ@mail.gmail.com>

Done, see
*Java Wrapping VTK 8.90 fails in Windows*:
https://gitlab.kitware.com/vtk/vtk/issues/17485
There is also a* windows_path.bat is incorrect* issue:
https://gitlab.kitware.com/vtk/vtk/issues/17484

Regards
   Andrew

On Tue, Jan 15, 2019 at 2:24 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Mon, Jan 14, 2019 at 15:43:00 +1100, Andrew Maclean wrote:
> > Currently Java wrapping fails in Windows.
>
> Could you please open an issue with details? I'll have to get Java
> installed on a Windows machine here to dig into it myself.
>
> Thanks.
>
> --Ben
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190115/d2384627/attachment.html>

From drouin.simon at gmail.com  Mon Jan 14 23:47:06 2019
From: drouin.simon at gmail.com (Simon Drouin)
Date: Mon, 14 Jan 2019 23:47:06 -0500
Subject: [vtk-developers] find_package(vtk) not supporting version anymore
Message-ID: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>

Hi All,

It seems the recent changes in vtk-config.cmake have dropped support for
specifying a version when calling find_package( vtk ). It this the intended
new behaviour?

See the modified c++ example from the vtk source attached. The output of
cmake (3.10.1 on macOS 10.14) is the following:

CMake Error at CMakeLists.txt:6 (find_package):
Could not find a configuration file for package "VTK" that is compatible
with requested version "8.90.0".

The following configuration files were considered but not accepted:

/Users/simon/ibis/vtk-git/build-deb-qt-5.9.7-osx-10.10/vtk-config.cmake,
version: unknown


cmake doesn't seem to be able to determine the version now.

s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190114/f3d4a903/attachment.html>
-------------- next part --------------
cmake_minimum_required(VERSION 3.3...3.12 FATAL_ERROR)


PROJECT (Rendering)

find_package(VTK 8.90.0 REQUIRED COMPONENTS CommonCore
FiltersSources
InteractionStyle
RenderingOpenGL2 )

set(RENDERING_EXAMPLES_SRCS
  Cylinder
  )

foreach(name ${RENDERING_EXAMPLES_SRCS})
  add_executable(${name} MACOSX_BUNDLE ${name}.cxx)
  target_link_libraries(${name} ${VTK_LIBRARIES} )
endforeach()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cylinder.cxx
Type: application/octet-stream
Size: 2973 bytes
Desc: not available
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190114/f3d4a903/attachment.obj>

From bill.lorensen at gmail.com  Tue Jan 15 00:43:38 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 14 Jan 2019 21:43:38 -0800
Subject: [vtk-developers] find_package(vtk) not supporting version
 anymore
In-Reply-To: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
References: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
Message-ID: <CADZJ4hOHDxcVqeEW774nkTJDGzQBynrvucysrDCj-UBKK_axhw@mail.gmail.com>

Have you completely removed your VTK_DIR?

On Mon, Jan 14, 2019, 8:47 PM Simon Drouin <drouin.simon at gmail.com wrote:

> Hi All,
>
> It seems the recent changes in vtk-config.cmake have dropped support for
> specifying a version when calling find_package( vtk ). It this the intended
> new behaviour?
>
> See the modified c++ example from the vtk source attached. The output of
> cmake (3.10.1 on macOS 10.14) is the following:
>
> CMake Error at CMakeLists.txt:6 (find_package):
> Could not find a configuration file for package "VTK" that is compatible
> with requested version "8.90.0".
>
> The following configuration files were considered but not accepted:
>
> /Users/simon/ibis/vtk-git/build-deb-qt-5.9.7-osx-10.10/vtk-config.cmake,
> version: unknown
>
>
> cmake doesn't seem to be able to determine the version now.
>
> s.
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190114/7ea01ad8/attachment.html>

From bill.lorensen at gmail.com  Tue Jan 15 01:00:19 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 14 Jan 2019 22:00:19 -0800
Subject: [vtk-developers] find_package(vtk) not supporting version
 anymore
In-Reply-To: <CADZJ4hOHDxcVqeEW774nkTJDGzQBynrvucysrDCj-UBKK_axhw@mail.gmail.com>
References: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
 <CADZJ4hOHDxcVqeEW774nkTJDGzQBynrvucysrDCj-UBKK_axhw@mail.gmail.com>
Message-ID: <CADZJ4hPcSVdUYtSVLAamNXyPbbRdBsLWA4G1uN=8fz=E5WQKyQ@mail.gmail.com>

Simon,

 tried on my cmakelists and it also fails for me.
I get the same error as you did.
Bill

On Mon, Jan 14, 2019 at 9:43 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Have you completely removed your VTK_DIR?
>
> On Mon, Jan 14, 2019, 8:47 PM Simon Drouin <drouin.simon at gmail.com wrote:
>>
>> Hi All,
>>
>> It seems the recent changes in vtk-config.cmake have dropped support for specifying a version when calling find_package( vtk ). It this the intended new behaviour?
>>
>> See the modified c++ example from the vtk source attached. The output of cmake (3.10.1 on macOS 10.14) is the following:
>>
>> CMake Error at CMakeLists.txt:6 (find_package):
>> Could not find a configuration file for package "VTK" that is compatible
>> with requested version "8.90.0".
>>
>> The following configuration files were considered but not accepted:
>>
>> /Users/simon/ibis/vtk-git/build-deb-qt-5.9.7-osx-10.10/vtk-config.cmake, version: unknown
>>
>>
>> cmake doesn't seem to be able to determine the version now.
>>
>> s.
>> _______________________________________________
>> 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://vtk.org/mailman/listinfo/vtk-developers
>>


-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Tue Jan 15 09:38:04 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 15 Jan 2019 09:38:04 -0500
Subject: [vtk-developers] find_package(vtk) not supporting version
 anymore
In-Reply-To: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
References: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
Message-ID: <20190115143804.GB22581@megas.kitware.com>

On Mon, Jan 14, 2019 at 23:47:06 -0500, Simon Drouin wrote:
> It seems the recent changes in vtk-config.cmake have dropped support for
> specifying a version when calling find_package( vtk ). It this the intended
> new behaviour?
> 
> See the modified c++ example from the vtk source attached. The output of
> cmake (3.10.1 on macOS 10.14) is the following:
> 
> CMake Error at CMakeLists.txt:6 (find_package):
> Could not find a configuration file for package "VTK" that is compatible
> with requested version "8.90.0".
> 
> The following configuration files were considered but not accepted:
> 
> /Users/simon/ibis/vtk-git/build-deb-qt-5.9.7-osx-10.10/vtk-config.cmake,
> version: unknown

Ah, this is with the `vtk-config.cmake` at the top-level of the build
tree. It doesn't have a version file beside it. MR coming up soon.

--Ben

From ben.boeckel at kitware.com  Tue Jan 15 09:41:06 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 15 Jan 2019 09:41:06 -0500
Subject: [vtk-developers] find_package(vtk) not supporting version
 anymore
In-Reply-To: <20190115143804.GB22581@megas.kitware.com>
References: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
 <20190115143804.GB22581@megas.kitware.com>
Message-ID: <20190115144106.GC22581@megas.kitware.com>

On Tue, Jan 15, 2019 at 09:38:04 -0500, Ben Boeckel wrote:
> Ah, this is with the `vtk-config.cmake` at the top-level of the build
> tree. It doesn't have a version file beside it. MR coming up soon.

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5069

--Ben

From drouin.simon at gmail.com  Tue Jan 15 15:55:47 2019
From: drouin.simon at gmail.com (Simon Drouin)
Date: Tue, 15 Jan 2019 15:55:47 -0500
Subject: [vtk-developers] find_package(vtk) not supporting version
 anymore
In-Reply-To: <20190115144106.GC22581@megas.kitware.com>
References: <CABKYObZNd8PCLhbWYu=Ov3FXTb8P1oEa-SC_+d04MEQXDG+Vzw@mail.gmail.com>
 <20190115143804.GB22581@megas.kitware.com>
 <20190115144106.GC22581@megas.kitware.com>
Message-ID: <CABKYObbZNyJy1hSaQufM3JZy1tXLm17bokzWoyAwQM+xHm9Bmw@mail.gmail.com>

Excellent. I just tested the MR and it works here.

On Tue, Jan 15, 2019 at 9:41 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Tue, Jan 15, 2019 at 09:38:04 -0500, Ben Boeckel wrote:
> > Ah, this is with the `vtk-config.cmake` at the top-level of the build
> > tree. It doesn't have a version file beside it. MR coming up soon.
>
>     https://gitlab.kitware.com/vtk/vtk/merge_requests/5069
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190115/16593cab/attachment.html>

From sean at rogue-research.com  Tue Jan 15 16:11:10 2019
From: sean at rogue-research.com (Sean McBride)
Date: Tue, 15 Jan 2019 16:11:10 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190102192353.GA24527@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
Message-ID: <20190115211110.394621553@mail.rogue-research.com>

On Wed, 2 Jan 2019 14:23:53 -0500, Ben Boeckel via vtk-developers said:

>  - Changed cache variables:
>    * Module and group flags:
>      - `Module_<MMM>` -> `VTK_MODULE_ENABLE_<MMM>`
>      - `VTK_Group_<MMM>` -> `VTK_GROUP_ENABLE_<MMM>`

I'll updated my buildbot scripts with the above (and below) renames.

>      - Values are no longer boolean, but instead 5-state:
>        * `YES`: Must be built
>        * `NO`: Must not be built (turns off modules requiring it;
>          errors if required by a `YES` module)
>        * `WANT`: Build if possible
>        * `DONT_WANT`: Build only if necessary
>        * `DEFAULT`: Use group (for modules) and `VTK_BUILD_ALL_MODULES`
>          instead

So they are strings I guess?

>      - `VTK_USE_SYSTEM_<MMM>` -> `VTK_MODULE_USE_EXTERNAL_<MMM>`
>        Third party modules which don't support an external version no
>        longer have an option available.

This new string is so long that in ccmake I only see:

 VTK_MODULE_USE_EXTERNAL_VTK_do  *OFF                                                                                                                                             
 VTK_MODULE_USE_EXTERNAL_VTK_ei  *OFF                                                                                                                                             
 VTK_MODULE_USE_EXTERNAL_VTK_ex  *OFF                                                                                                                                             
 VTK_MODULE_USE_EXTERNAL_VTK_fr  *OFF                                                                                                                                             

Is there anyway to resize those columns?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From ben.boeckel at kitware.com  Tue Jan 15 16:45:15 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 15 Jan 2019 16:45:15 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190115211110.394621553@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190115211110.394621553@mail.rogue-research.com>
Message-ID: <20190115214515.GA21921@megas.kitware.com>

On Tue, Jan 15, 2019 at 16:11:10 -0500, Sean McBride wrote:
> I'll updated my buildbot scripts with the above (and below) renames.

Thanks.

> So they are strings I guess?

Yes.

> This new string is so long that in ccmake I only see:
> 
>  VTK_MODULE_USE_EXTERNAL_VTK_do  *OFF
>  VTK_MODULE_USE_EXTERNAL_VTK_ei  *OFF
>  VTK_MODULE_USE_EXTERNAL_VTK_ex  *OFF
>  VTK_MODULE_USE_EXTERNAL_VTK_fr  *OFF
> 
> Is there anyway to resize those columns?

Unfortunately, no :( . I've filed a CMake issue about it:

    https://gitlab.kitware.com/cmake/cmake/issues/18809

--Ben

From bill.lorensen at gmail.com  Tue Jan 15 17:24:33 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 15 Jan 2019 14:24:33 -0800
Subject: [vtk-developers] Status Log for new module system
Message-ID: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>

Ben, since the new module system no longer provides feedback on status
during config time, could that output be redirected to
build_dir/CMakeFiles/CMakeStatus.lo
much like
CMakeFiles/CMakeOutput.log
and
CMakeFiles/CMakeError.log

Bill
-- 
Unpaid intern in BillsParadise at noware dot com

From bill.lorensen at gmail.com  Tue Jan 15 17:26:58 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 15 Jan 2019 14:26:58 -0800
Subject: [vtk-developers] Status Log for new module system
In-Reply-To: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>
References: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>
Message-ID: <CADZJ4hM6QgnhH57hzeTT1cx_bPEu4MNxmX_+hZBf5aVWvDmj3A@mail.gmail.com>

Or
VTKStatus.log

On Tue, Jan 15, 2019 at 2:24 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Ben, since the new module system no longer provides feedback on status
> during config time, could that output be redirected to
> build_dir/CMakeFiles/CMakeStatus.lo
> much like
> CMakeFiles/CMakeOutput.log
> and
> CMakeFiles/CMakeError.log
>
> Bill
> --
> Unpaid intern in BillsParadise at noware dot com



-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Wed Jan 16 10:35:37 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 16 Jan 2019 10:35:37 -0500
Subject: [vtk-developers] Status Log for new module system
In-Reply-To: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>
References: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>
Message-ID: <20190116153537.GA7077@megas.kitware.com>

On Tue, Jan 15, 2019 at 14:24:33 -0800, Bill Lorensen wrote:
> Ben, since the new module system no longer provides feedback on status
> during config time, could that output be redirected to
> build_dir/CMakeFiles/CMakeStatus.lo
> much like
> CMakeFiles/CMakeOutput.log
> and
> CMakeFiles/CMakeError.log

Yeah, I can look at doing that. I might not get to it until next week
though.

--Ben

From bill.lorensen at gmail.com  Wed Jan 16 11:06:24 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 16 Jan 2019 08:06:24 -0800
Subject: [vtk-developers] Status Log for new module system
In-Reply-To: <20190116153537.GA7077@megas.kitware.com>
References: <CADZJ4hM9ee8brooPV7o3qUuD7O+UUQkEW-xR-YV9-HjAdESikg@mail.gmail.com>
 <20190116153537.GA7077@megas.kitware.com>
Message-ID: <CADZJ4hOx6RsCx-1q5eZbeTBAokAPikiAecBaQ3DGy6i=9HcvFQ@mail.gmail.com>

Great, thanks

On Wed, Jan 16, 2019, 7:35 AM Ben Boeckel <ben.boeckel at kitware.com wrote:

> On Tue, Jan 15, 2019 at 14:24:33 -0800, Bill Lorensen wrote:
> > Ben, since the new module system no longer provides feedback on status
> > during config time, could that output be redirected to
> > build_dir/CMakeFiles/CMakeStatus.lo
> > much like
> > CMakeFiles/CMakeOutput.log
> > and
> > CMakeFiles/CMakeError.log
>
> Yeah, I can look at doing that. I might not get to it until next week
> though.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190116/dbe0b6eb/attachment.html>

From ben.boeckel at kitware.com  Thu Jan 17 11:38:12 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 17 Jan 2019 11:38:12 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190110220712.GA21739@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
Message-ID: <20190117163812.GA17074@megas.kitware.com>

On Thu, Jan 10, 2019 at 17:07:12 -0500, Ben Boeckel wrote:
> >   - mun: shared+kits Python tests are failing. I suspect a missing PATH
> >     entry or the like. Will investgate tomorrow.
> 
> Still not working. Needs more investigation.

Actually turned out to be some mismatches between setters and getters in
the module system itself. MR for fixing it is here:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/5077

Now all `mun` builds are just failing examples (TBB information needs
forwarding through `vtk-config.cmake`) and 2 other failures, one for the
VPIC thing and an LSDyna failure other machines are seeing.

--Ben

From sean at rogue-research.com  Thu Jan 17 12:27:33 2019
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 17 Jan 2019 12:27:33 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190102192353.GA24527@rotor.localdomain>
References: <20190102192353.GA24527@rotor.localdomain>
Message-ID: <20190117172733.49949388@mail.rogue-research.com>

Ben,

If I create a fresh bin directory and change only VTK_FORBID_DOWNLOADS to NO, then configure and build, I get an error:

-------------------
CMake Error at /Applications/CMake.app/Contents/share/cmake-3.13/Modules/ExternalData.cmake:1121 (message):
  

  Object
  SHA512=d46218c565aa140b706c01b41bce9179106a55875f669bb1a5c2227efa677e9a8066cd5b28ee2be806ebec93d7ab72040562491a963c3bf1c3606db239097b13
  not found at:

    (No ExternalData_URL_TEMPLATES given)
-------------------

So I set BUILD_TESTING to off, but that didn't help.

Then I noticed a VTK_BUILD_TESTING, is that new?  Turning it off fixed it.  So it's clearly different from BUILD_TESTING.  The setting description doesn't help:

BUILD_TESTING: Build the testing tree.                                                                                                                                             
VTK_BUILD_TESTING: Build all modules by default                                                                                                                                    

Is that last description even right?  Why have both these settings anyway?  Should setting VTK_FORBID_DOWNLOADS to NO force testing to NO also?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From ben.boeckel at kitware.com  Thu Jan 17 12:57:49 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 17 Jan 2019 12:57:49 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190117172733.49949388@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190117172733.49949388@mail.rogue-research.com>
Message-ID: <20190117175749.GA10673@megas.kitware.com>

On Thu, Jan 17, 2019 at 12:27:33 -0500, Sean McBride wrote:
> So I set BUILD_TESTING to off, but that didn't help.

`BUILD_TESTING` is a CTest variable which makes `add_test` a no-op.

> Then I noticed a VTK_BUILD_TESTING, is that new?  Turning it off fixed
> it.  So it's clearly different from BUILD_TESTING.  The setting
> description doesn't help:
> 
> BUILD_TESTING: Build the testing tree
> VTK_BUILD_TESTING: Build all modules by default

Yeah, the description looks like copy-pasta. It has 3 settings:

  ON: if a module is on, build its tests
  WANT: if a module is on, try to turn on test dependencies and build
        tests if those are all available
  OFF: no module tests

How about "Build module testing directories"?

> Is that last description even right?  Why have both these settings
> anyway?  Should setting VTK_FORBID_DOWNLOADS to NO force testing to NO
> also?

I wasn't aware of `VTK_FORBID_DOWNLOADS`. It can be taken into account
before passing it via `ENABLE_TESTS` to `vtk_module_scan`.

--Ben

From sean at rogue-research.com  Thu Jan 17 13:52:22 2019
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 17 Jan 2019 13:52:22 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190117175749.GA10673@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190117172733.49949388@mail.rogue-research.com>
 <20190117175749.GA10673@megas.kitware.com>
Message-ID: <20190117185222.886881895@mail.rogue-research.com>

On Thu, 17 Jan 2019 12:57:49 -0500, Ben Boeckel said:

>> BUILD_TESTING: Build the testing tree
>> VTK_BUILD_TESTING: Build all modules by default
>
>Yeah, the description looks like copy-pasta. It has 3 settings:
>
>  ON: if a module is on, build its tests
>  WANT: if a module is on, try to turn on test dependencies and build
>        tests if those are all available
>  OFF: no module tests
>
>How about "Build module testing directories"?

Sure.

>> Is that last description even right?  Why have both these settings
>> anyway?  Should setting VTK_FORBID_DOWNLOADS to NO force testing to NO
>> also?
>
>I wasn't aware of `VTK_FORBID_DOWNLOADS`. It can be taken into account
>before passing it via `ENABLE_TESTS` to `vtk_module_scan`.

Thanks.


Next, I'm trying to build ITK master against VTK master and get:

 CMake Error at Modules/Bridge/VtkGlue/CMakeLists.txt:38 (vtk_module_config):
   Unknown CMake command "vtk_module_config".

I'm gonna guess this too is related to this 'new module system' stuff, yes?  Does ITK need to change?  Or is VTK missing some backward compatibility something?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From ben.boeckel at kitware.com  Thu Jan 17 14:06:56 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 17 Jan 2019 14:06:56 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190117185222.886881895@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190117172733.49949388@mail.rogue-research.com>
 <20190117175749.GA10673@megas.kitware.com>
 <20190117185222.886881895@mail.rogue-research.com>
Message-ID: <20190117190656.GA3098@megas.kitware.com>

On Thu, Jan 17, 2019 at 13:52:22 -0500, Sean McBride wrote:
> On Thu, 17 Jan 2019 12:57:49 -0500, Ben Boeckel said:
> >How about "Build module testing directories"?
> 
> Sure.
> 
> >> Is that last description even right?  Why have both these settings
> >> anyway?  Should setting VTK_FORBID_DOWNLOADS to NO force testing to NO
> >> also?
> >
> >I wasn't aware of `VTK_FORBID_DOWNLOADS`. It can be taken into account
> >before passing it via `ENABLE_TESTS` to `vtk_module_scan`.
> 
> Thanks.

MR up shortly.

> Next, I'm trying to build ITK master against VTK master and get:
> 
>  CMake Error at Modules/Bridge/VtkGlue/CMakeLists.txt:38 (vtk_module_config):
>    Unknown CMake command "vtk_module_config".
> 
> I'm gonna guess this too is related to this 'new module system' stuff,
> yes?  Does ITK need to change?  Or is VTK missing some backward
> compatibility something?

There's no provided backwards compat bridge. Looking, I suspect a block
like:

    elseif (VTK_VERSION VERSION_LESS 8.90)

should wrap the existing `else` and a new block be added.

--Ben

From bill.lorensen at gmail.com  Thu Jan 17 14:23:02 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 17 Jan 2019 11:23:02 -0800
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190117190656.GA3098@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190117172733.49949388@mail.rogue-research.com>
 <20190117175749.GA10673@megas.kitware.com>
 <20190117185222.886881895@mail.rogue-research.com>
 <20190117190656.GA3098@megas.kitware.com>
Message-ID: <CADZJ4hNJWE0vao-2ZxJQTVabRt=vjhv+pX=03VqPUa8gsn6Kww@mail.gmail.com>

Sean, I'm working on getting the VTKExamples working with both old and new
VTK modules. I've got a working solution for individual examples, e.g.
https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Cube/#cmakeliststxt

Next I'll tackle building the whole suite.

Bill

On Thu, Jan 17, 2019, 11:07 AM Ben Boeckel via vtk-developers <
vtk-developers at vtk.org wrote:

> On Thu, Jan 17, 2019 at 13:52:22 -0500, Sean McBride wrote:
> > On Thu, 17 Jan 2019 12:57:49 -0500, Ben Boeckel said:
> > >How about "Build module testing directories"?
> >
> > Sure.
> >
> > >> Is that last description even right?  Why have both these settings
> > >> anyway?  Should setting VTK_FORBID_DOWNLOADS to NO force testing to NO
> > >> also?
> > >
> > >I wasn't aware of `VTK_FORBID_DOWNLOADS`. It can be taken into account
> > >before passing it via `ENABLE_TESTS` to `vtk_module_scan`.
> >
> > Thanks.
>
> MR up shortly.
>
> > Next, I'm trying to build ITK master against VTK master and get:
> >
> >  CMake Error at Modules/Bridge/VtkGlue/CMakeLists.txt:38
> (vtk_module_config):
> >    Unknown CMake command "vtk_module_config".
> >
> > I'm gonna guess this too is related to this 'new module system' stuff,
> > yes?  Does ITK need to change?  Or is VTK missing some backward
> > compatibility something?
>
> There's no provided backwards compat bridge. Looking, I suspect a block
> like:
>
>     elseif (VTK_VERSION VERSION_LESS 8.90)
>
> should wrap the existing `else` and a new block be added.
>
> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190117/4c66c0f9/attachment.html>

From bill.lorensen at gmail.com  Fri Jan 18 17:11:21 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 18 Jan 2019 14:11:21 -0800
Subject: [vtk-developers] vtk_module_autoinit in new module system
Message-ID: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>

Ben,

I'm curious why with the new module system we need to add
vtk_module_autoinit for the targets in the new system.

I never used it in the old system.'

Bill

-- 
Unpaid intern in BillsParadise at noware dot com

From cory.quammen at kitware.com  Mon Jan 21 10:22:40 2019
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 21 Jan 2019 10:22:40 -0500
Subject: [vtk-developers] VTK Discourse forum is now available
Message-ID: <CAB5Fpx6F+Bqq8QctcdPbii4m=RKnUcQVGRVZB9D-zJS0zQXbcQ@mail.gmail.com>

Hello VTK community,

Following up on our previous discussion about transitioning the VTK
mailing lists to Discourse [1], we now have a Discourse forum ready to
use to discuss all things VTK. You can find it at

https://discourse.vtk.org/

You can sign up for the web site using your Google or GitHub accounts
if you prefer, otherwise you can register with a user name and
password.

Please try it out and leave any feedback you might have under the
"Site Feedback" category (https://discourse.vtk.org/c/site-feedback)
on the site.

To set up Discourse in mailing list mode, please see:

https://discourse.vtk.org/t/using-discourse-as-a-mailing-list/

While we expect the bulk of VTK-related discussion to transition to
Discourse fairly rapidly in the near term, the current
vtkusers at vtk.org and vtk-developers at vtk.org mailing lists will remain
active until at least the middle of 2019, and the archives from these
lists will remain available after that.

See you on discourse.vtk.org!

Thanks,
Cory

[1] https://markmail.org/thread/2dricthoo3ugw7jv

-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.

From ben.boeckel at kitware.com  Tue Jan 22 10:31:40 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 22 Jan 2019 10:31:40 -0500
Subject: [vtk-developers] vtk_module_autoinit in new module system
In-Reply-To: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>
References: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>
Message-ID: <20190122153140.GA13979@megas.kitware.com>

On Fri, Jan 18, 2019 at 14:11:21 -0800, Bill Lorensen wrote:
> I'm curious why with the new module system we need to add
> vtk_module_autoinit for the targets in the new system.
> 
> I never used it in the old system.'

That's because `VTK_DEFINITIONS` had the entries after `find_package`
based on the passed-in components. The new module system instead prefers
to attach the required definition (and header file generation) to
exactly which targets need them.

--Ben

From elvis.stansvik at orexplore.com  Tue Jan 22 12:15:54 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 22 Jan 2019 18:15:54 +0100
Subject: [vtk-developers] vtk_module_autoinit in new module system
In-Reply-To: <20190122153140.GA13979@megas.kitware.com>
References: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>
 <20190122153140.GA13979@megas.kitware.com>
Message-ID: <CAE-7VJ=OnkdY8CrAxh_u2fkk1rj=UU0kE-UGprCbf7mEjGG3OA@mail.gmail.com>

Den tis 22 jan. 2019 16:31Ben Boeckel via vtk-developers <
vtk-developers at vtk.org> skrev:

> On Fri, Jan 18, 2019 at 14:11:21 -0800, Bill Lorensen wrote:
> > I'm curious why with the new module system we need to add
> > vtk_module_autoinit for the targets in the new system.
> >
> > I never used it in the old system.'
>
> That's because `VTK_DEFINITIONS` had the entries after `find_package`
> based on the passed-in components. The new module system instead prefers
> to attach the required definition (and header file generation) to
> exactly which targets need them.
>

I don't exactly understand, but I'm by no means a cmake guru, but couldn't
the required -D flags be passed through the target interface definitions of
the targets that VTK exports, then I could get them through just
target_link_libraries(stuff I need)?

Just hoping there's some way of getting rid of the double bookkeeping since
it feels like a step back maintenancewise from a user pov if I have to
remember to do this.

Elvis


> --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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190122/a144dfb3/attachment.html>

From ben.boeckel at kitware.com  Tue Jan 22 12:36:56 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 22 Jan 2019 12:36:56 -0500
Subject: [vtk-developers] vtk_module_autoinit in new module system
In-Reply-To: <CAE-7VJ=OnkdY8CrAxh_u2fkk1rj=UU0kE-UGprCbf7mEjGG3OA@mail.gmail.com>
References: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>
 <20190122153140.GA13979@megas.kitware.com>
 <CAE-7VJ=OnkdY8CrAxh_u2fkk1rj=UU0kE-UGprCbf7mEjGG3OA@mail.gmail.com>
Message-ID: <20190122173656.GA21959@megas.kitware.com>

On Tue, Jan 22, 2019 at 18:15:54 +0100, Elvis Stansvik wrote:
> I don't exactly understand, but I'm by no means a cmake guru, but couldn't
> the required -D flags be passed through the target interface definitions of
> the targets that VTK exports, then I could get them through just
> target_link_libraries(stuff I need)?

Brad and I had discussions about this, but no. Let's take
`vtkRenderingCore` as an example. First, you need to know what other
targets the consuming target uses (not possible with generator
expressions). Once you have that list, you need to filter down which
ones `IMPLEMENT vtkRenderingCore`, count them and join their library
names using `,`. This results in something like this:

    #define vtkRenderingCore_AUTOINIT 2(vtkRenderingOpenGL2,vtkRenderingFoobar)

This then is written to a file since MSVC doesn't support commas (or
parentheses; I forget which) on the command line. The resulting
generated `-D` flag is:

    -DvtkRenderingCore_AUTOINIT_INCLUDE=\".../vtkModuleAutoInit_${hash}.h\"

where `${hash}` is the MD5 of the set of modules being linked (to avoid
collisions when linking multiple times).

The old module system just gave you everything possible for all usages
via `VTK_DEFINITIONS`. Now, you get exactly what is necessary, nothing
more.

> Just hoping there's some way of getting rid of the double bookkeeping since
> it feels like a step back maintenancewise from a user pov if I have to
> remember to do this.

I agree that it is less handy, but there's not much to be done with
CMake features available today.

--Ben

From elvis.stansvik at orexplore.com  Tue Jan 22 13:05:13 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 22 Jan 2019 19:05:13 +0100
Subject: [vtk-developers] vtk_module_autoinit in new module system
In-Reply-To: <20190122173656.GA21959@megas.kitware.com>
References: <CADZJ4hPu_80p2a1thUMa6DvZ4fOZF7YH_iED=G8agW==XAeXHA@mail.gmail.com>
 <20190122153140.GA13979@megas.kitware.com>
 <CAE-7VJ=OnkdY8CrAxh_u2fkk1rj=UU0kE-UGprCbf7mEjGG3OA@mail.gmail.com>
 <20190122173656.GA21959@megas.kitware.com>
Message-ID: <CAE-7VJmFs86SuwUN0n-KMRjkrRZdBdDDuqhCec+Ky9aaDUt6wA@mail.gmail.com>

Den tis 22 jan. 2019 kl 18:36 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Tue, Jan 22, 2019 at 18:15:54 +0100, Elvis Stansvik wrote:
> > I don't exactly understand, but I'm by no means a cmake guru, but couldn't
> > the required -D flags be passed through the target interface definitions of
> > the targets that VTK exports, then I could get them through just
> > target_link_libraries(stuff I need)?
>
> Brad and I had discussions about this, but no. Let's take
> `vtkRenderingCore` as an example. First, you need to know what other
> targets the consuming target uses (not possible with generator
> expressions). Once you have that list, you need to filter down which
> ones `IMPLEMENT vtkRenderingCore`, count them and join their library
> names using `,`. This results in something like this:
>
>     #define vtkRenderingCore_AUTOINIT 2(vtkRenderingOpenGL2,vtkRenderingFoobar)
>
> This then is written to a file since MSVC doesn't support commas (or
> parentheses; I forget which) on the command line. The resulting
> generated `-D` flag is:
>
>     -DvtkRenderingCore_AUTOINIT_INCLUDE=\".../vtkModuleAutoInit_${hash}.h\"
>
> where `${hash}` is the MD5 of the set of modules being linked (to avoid
> collisions when linking multiple times).

Ah, now I see what kludge this would be. Thanks for clarifying.

I never really thought of how those defines were structured, it "just worked".

>
> The old module system just gave you everything possible for all usages
> via `VTK_DEFINITIONS`. Now, you get exactly what is necessary, nothing
> more.
>
> > Just hoping there's some way of getting rid of the double bookkeeping since
> > it feels like a step back maintenancewise from a user pov if I have to
> > remember to do this.
>
> I agree that it is less handy, but there's not much to be done with
> CMake features available today.

Fair enough.

Elvis

>
> --Ben

From aron.helser at kitware.com  Tue Jan 22 17:32:52 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Tue, 22 Jan 2019 17:32:52 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows build?
Message-ID: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>

Hello!
I'm seeing a weird failure with a recent vtk master on Windows.
I'm doing a debug static build, and running ctest, all tests with a window
are segfaulting after this warning:

Generic Warning: In C:\akit\vtk\src\Rendering\Core\vtkRenderWindow.cxx,
line 35
Error: no override found for 'vtkRenderWindow'.

A shared build does not have this problem. It seems like the OpenGL object
factory is failing somehow with a static build? Any ideas?

Thanks,
Aron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190122/e4dc2216/attachment.html>

From bill.lorensen at gmail.com  Wed Jan 23 01:24:07 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 22 Jan 2019 22:24:07 -0800
Subject: [vtk-developers] libxml2 link errors
Message-ID: <CADZJ4hPtJkbwnUa1setAuUhqPiJoZne7=QFp3rF9EwKkfOBOiA@mail.gmail.com>

Ben,
IOn my MacOS, High Sierra 10.13.6 I get this link error:

[ 56%] Linking CXX shared library ../../lib/libvtkIOInfovis-8.90.dylib

Undefined symbols for architecture x86_64:

  "_vtk_libxml2_xmlDocGetRootElement", referenced from:

      vtkXMLTreeReader::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*) in
vtkXMLTreeReader.cxx.o

  "_vtk_libxml2_xmlFreeDoc", referenced from:

      vtkXMLTreeReader::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*) in
vtkXMLTreeReader.cxx.o

  "_vtk_libxml2_xmlReadFile", referenced from:

      vtkXMLTreeReader::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*) in
vtkXMLTreeReader.cxx.o

  "_vtk_libxml2_xmlReadMemory", referenced from:

      vtkXMLTreeReader::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*) in
vtkXMLTreeReader.cxx.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [lib/libvtkIOInfovis-8.90.8.90.0.dylib] Error 1

make[1]: *** [IO/Infovis/CMakeFiles/IOInfovis.dir/all] Error 2


-- 
Unpaid intern in BillsParadise at noware dot com

From bill.lorensen at gmail.com  Wed Jan 23 01:28:06 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 22 Jan 2019 22:28:06 -0800
Subject: [vtk-developers] libxml2 link errors
In-Reply-To: <CADZJ4hPtJkbwnUa1setAuUhqPiJoZne7=QFp3rF9EwKkfOBOiA@mail.gmail.com>
References: <CADZJ4hPtJkbwnUa1setAuUhqPiJoZne7=QFp3rF9EwKkfOBOiA@mail.gmail.com>
Message-ID: <CADZJ4hM9RUEBjvgHCp8+WewKJ0RAPJs+dwUsnFLgMe7MdXm48w@mail.gmail.com>

Ben,

Disregard, I cleaned the ThirdParty/linxml2 tree, and rebuilt.

It's OK now.

Bill

On Tue, Jan 22, 2019 at 10:24 PM Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Ben,
> IOn my MacOS, High Sierra 10.13.6 I get this link error:
>
> [ 56%] Linking CXX shared library ../../lib/libvtkIOInfovis-8.90.dylib
>
> Undefined symbols for architecture x86_64:
>
>   "_vtk_libxml2_xmlDocGetRootElement", referenced from:
>
>       vtkXMLTreeReader::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*) in
> vtkXMLTreeReader.cxx.o
>
>   "_vtk_libxml2_xmlFreeDoc", referenced from:
>
>       vtkXMLTreeReader::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*) in
> vtkXMLTreeReader.cxx.o
>
>   "_vtk_libxml2_xmlReadFile", referenced from:
>
>       vtkXMLTreeReader::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*) in
> vtkXMLTreeReader.cxx.o
>
>   "_vtk_libxml2_xmlReadMemory", referenced from:
>
>       vtkXMLTreeReader::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*) in
> vtkXMLTreeReader.cxx.o
>
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> make[2]: *** [lib/libvtkIOInfovis-8.90.8.90.0.dylib] Error 1
>
> make[1]: *** [IO/Infovis/CMakeFiles/IOInfovis.dir/all] Error 2
>
>
> --
> Unpaid intern in BillsParadise at noware dot com



-- 
Unpaid intern in BillsParadise at noware dot com

From ben.boeckel at kitware.com  Wed Jan 23 09:05:03 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 09:05:03 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
Message-ID: <20190123140503.GB30183@megas.kitware.com>

On Tue, Jan 22, 2019 at 17:32:52 -0500, Aron Helser via vtk-developers wrote:
> I'm seeing a weird failure with a recent vtk master on Windows.
> I'm doing a debug static build, and running ctest, all tests with a window
> are segfaulting after this warning:
> 
> Generic Warning: In C:\akit\vtk\src\Rendering\Core\vtkRenderWindow.cxx,
> line 35
> Error: no override found for 'vtkRenderWindow'.
> 
> A shared build does not have this problem. It seems like the OpenGL object
> factory is failing somehow with a static build? Any ideas?

Hmm. Static builds on the dashboard were working here:

    https://open.cdash.org/index.php?compare1=61&filtercount=1&field1=revision&project=VTK&showfilters=0&limit=100&value1=25d2722c7e8d3a423397c3df0cc7173ae6a6f44a&showfeed=0

but it seems that `master` doesn't like it as much (though, AFAICT, only
for Python import reasons, not object factory failures). What does your
CMake code look like?

--Ben

From aron.helser at kitware.com  Wed Jan 23 10:12:18 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Wed, 23 Jan 2019 10:12:18 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <20190123140503.GB30183@megas.kitware.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
 <20190123140503.GB30183@megas.kitware.com>
Message-ID: <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>

Here's one from master with the same symptom:
https://open.cdash.org/testDetails.php?test=722623728&build=5703510

I'm doing
cmake -G Ninja -C ..\build_py3.cmake ../src

with this build_py3.cmake:

set(BUILD_SHARED_LIBS "OFF" CACHE BOOL "")
set(BUILD_TESTING "ON" CACHE BOOL "")
set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")
set(CMAKE_INSTALL_PREFIX "C:/akit/vtk/install" CACHE PATH "")
set(VTK_ENABLE_PYTHON "ON" CACHE BOOL "")
set(VTK_PYTHON_VERSION "3" CACHE STRING "")
set(VTK_LEGACY_REMOVE ON CACHE BOOL "")

set(VTK_MODULE_ENABLE_VTK_RenderingOpenVR YES CACHE BOOL "")
set(OpenVR_INCLUDE_DIR "C:/akit/openvr/headers" CACHE PATH "")
set(OpenVR_LIBRARY "C:/akit/openvr/lib/win64/openvr_api.lib" CACHE FILEPATH
"")
set(FFMPEG_ROOT "c:/akit/mineview/src/ffmpeg" CACHE PATH "")
set(VTK_MODULE_ENABLE_VTK_IOFFMPEG YES CACHE BOOL "")

Hopefully the OpenVR and FFMPEG stuff aren't relevant, and can be omitted.
I'll test that.
I'll attach my cmakecache, too

Thanks!

On Wed, Jan 23, 2019 at 9:05 AM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Tue, Jan 22, 2019 at 17:32:52 -0500, Aron Helser via vtk-developers
> wrote:
> > I'm seeing a weird failure with a recent vtk master on Windows.
> > I'm doing a debug static build, and running ctest, all tests with a
> window
> > are segfaulting after this warning:
> >
> > Generic Warning: In C:\akit\vtk\src\Rendering\Core\vtkRenderWindow.cxx,
> > line 35
> > Error: no override found for 'vtkRenderWindow'.
> >
> > A shared build does not have this problem. It seems like the OpenGL
> object
> > factory is failing somehow with a static build? Any ideas?
>
> Hmm. Static builds on the dashboard were working here:
>
>
> https://open.cdash.org/index.php?compare1=61&filtercount=1&field1=revision&project=VTK&showfilters=0&limit=100&value1=25d2722c7e8d3a423397c3df0cc7173ae6a6f44a&showfeed=0
>
> but it seems that `master` doesn't like it as much (though, AFAICT, only
> for Python import reasons, not object factory failures). What does your
> CMake code look like?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/0dd6d265/attachment-0001.html>
-------------- next part --------------
# This is the CMakeCache file.
# For build in directory: c:/akit/vtk/build
# It was generated by CMake: C:/Program Files/CMake/bin/cmake.exe
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.

########################
# EXTERNAL cache entries
########################

//Build VTK with shared libraries.
BUILD_SHARED_LIBS:BOOL=OFF

//Build the testing tree.
BUILD_TESTING:BOOL=ON

//Path to a program.
BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND

CMAKE_BUILD_TYPE:STRING=Debug

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe

//Flags used by the CXX compiler during all build types.
CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc

//Flags used by the CXX compiler during DEBUG builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=/MDd /Zi /Ob0 /Od /RTC1

//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=/MD /O1 /Ob1 /DNDEBUG

//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /DNDEBUG

//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=/MD /Zi /O2 /Ob1 /DNDEBUG

//Build with /MP flag enabled
CMAKE_CXX_MP_FLAG:BOOL=OFF

//The maximum number of processes for the /MP flag
CMAKE_CXX_MP_NUM_PROCESSORS:STRING=

//Libraries linked by default with all C++ applications.
CMAKE_CXX_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib

//C compiler
CMAKE_C_COMPILER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe

//Flags used by the C compiler during all build types.
CMAKE_C_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3

//Flags used by the C compiler during DEBUG builds.
CMAKE_C_FLAGS_DEBUG:STRING=/MDd /Zi /Ob0 /Od /RTC1

//Flags used by the C compiler during MINSIZEREL builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=/MD /O1 /Ob1 /DNDEBUG

//Flags used by the C compiler during RELEASE builds.
CMAKE_C_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /DNDEBUG

//Flags used by the C compiler during RELWITHDEBINFO builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=/MD /Zi /O2 /Ob1 /DNDEBUG

//Libraries linked by default with all C applications.
CMAKE_C_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib

//Flags used by the linker during all build types.
CMAKE_EXE_LINKER_FLAGS:STRING=/machine:x64

//Flags used by the linker during DEBUG builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL

//Flags used by the linker during MINSIZEREL builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO

//Flags used by the linker during RELEASE builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO

//Flags used by the linker during RELWITHDEBINFO builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//User executables (bin)
CMAKE_INSTALL_BINDIR:PATH=bin

//Read-only architecture-independent data (DATAROOTDIR)
CMAKE_INSTALL_DATADIR:PATH=

//Read-only architecture-independent data root (share)
CMAKE_INSTALL_DATAROOTDIR:PATH=share

//Documentation root (DATAROOTDIR/doc/PROJECT_NAME)
CMAKE_INSTALL_DOCDIR:PATH=

//C header files (include)
CMAKE_INSTALL_INCLUDEDIR:PATH=include

//Info documentation (DATAROOTDIR/info)
CMAKE_INSTALL_INFODIR:PATH=

//Object code libraries (lib)
CMAKE_INSTALL_LIBDIR:PATH=lib

//Program executables (libexec)
CMAKE_INSTALL_LIBEXECDIR:PATH=libexec

//Locale-dependent data (DATAROOTDIR/locale)
CMAKE_INSTALL_LOCALEDIR:PATH=

//Modifiable single-machine data (var)
CMAKE_INSTALL_LOCALSTATEDIR:PATH=var

//Man documentation (DATAROOTDIR/man)
CMAKE_INSTALL_MANDIR:PATH=

//C header files for non-gcc (/usr/include)
CMAKE_INSTALL_OLDINCLUDEDIR:PATH=/usr/include

CMAKE_INSTALL_PREFIX:PATH=C:/akit/vtk/install

//Run-time variable data (LOCALSTATEDIR/run)
CMAKE_INSTALL_RUNSTATEDIR:PATH=

//System admin executables (sbin)
CMAKE_INSTALL_SBINDIR:PATH=sbin

//Modifiable architecture-independent data (com)
CMAKE_INSTALL_SHAREDSTATEDIR:PATH=com

//Read-only single-machine data (etc)
CMAKE_INSTALL_SYSCONFDIR:PATH=etc

//Path to a program.
CMAKE_LINKER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe

//Program used to build from build.ninja files.
CMAKE_MAKE_PROGRAM:FILEPATH=C:/apps/ninja.exe

//Flags used by the linker during the creation of modules during
// all build types.
CMAKE_MODULE_LINKER_FLAGS:STRING=/machine:x64

//Flags used by the linker during the creation of modules during
// DEBUG builds.
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL

//Flags used by the linker during the creation of modules during
// MINSIZEREL builds.
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO

//Flags used by the linker during the creation of modules during
// RELEASE builds.
CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO

//Flags used by the linker during the creation of modules during
// RELWITHDEBINFO builds.
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL

//Value Computed by CMake
CMAKE_PROJECT_DESCRIPTION:STATIC=

//Value Computed by CMake
CMAKE_PROJECT_HOMEPAGE_URL:STATIC=

//Value Computed by CMake
CMAKE_PROJECT_NAME:STATIC=VTK

//RC compiler
CMAKE_RC_COMPILER:FILEPATH=C:/Program Files (x86)/Windows Kits/10/bin/10.0.17763.0/x64/rc.exe

//Flags for Windows Resource Compiler during all build types.
CMAKE_RC_FLAGS:STRING=/DWIN32

//Flags for Windows Resource Compiler during DEBUG builds.
CMAKE_RC_FLAGS_DEBUG:STRING=/D_DEBUG

//Flags for Windows Resource Compiler during MINSIZEREL builds.
CMAKE_RC_FLAGS_MINSIZEREL:STRING=

//Flags for Windows Resource Compiler during RELEASE builds.
CMAKE_RC_FLAGS_RELEASE:STRING=

//Flags for Windows Resource Compiler during RELWITHDEBINFO builds.
CMAKE_RC_FLAGS_RELWITHDEBINFO:STRING=

//Flags used by the linker during the creation of shared libraries
// during all build types.
CMAKE_SHARED_LINKER_FLAGS:STRING=/machine:x64

//Flags used by the linker during the creation of shared libraries
// during DEBUG builds.
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL

//Flags used by the linker during the creation of shared libraries
// during MINSIZEREL builds.
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO

//Flags used by the linker during the creation of shared libraries
// during RELEASE builds.
CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO

//Flags used by the linker during the creation of shared libraries
// during RELWITHDEBINFO builds.
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL

//If set, runtime paths are not added when installing shared libraries,
// but are added when building.
CMAKE_SKIP_INSTALL_RPATH:BOOL=OFF

//If set, runtime paths are not added when using shared libraries.
CMAKE_SKIP_RPATH:BOOL=OFF

//Flags used by the linker during the creation of static libraries
// during all build types.
CMAKE_STATIC_LINKER_FLAGS:STRING=/machine:x64

//Flags used by the linker during the creation of static libraries
// during DEBUG builds.
CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during the creation of static libraries
// during MINSIZEREL builds.
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during the creation of static libraries
// during RELEASE builds.
CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during the creation of static libraries
// during RELWITHDEBINFO builds.
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//If this value is on, makefiles will be generated without the
// .SILENT directive, and all commands will be echoed to the console
// during the make.  This is useful for debugging only. With Visual
// Studio IDE projects all commands are done without /nologo.
CMAKE_VERBOSE_MAKEFILE:BOOL=OFF

//Path to the coverage program that CTest uses for performing coverage
// inspection
COVERAGE_COMMAND:FILEPATH=COVERAGE_COMMAND-NOTFOUND

//Extra command line flags to pass to the coverage tool
COVERAGE_EXTRA_FLAGS:STRING=-l

//How many times to retry timed-out CTest submissions.
CTEST_SUBMIT_RETRY_COUNT:STRING=3

//How long to wait between timed-out CTest submissions.
CTEST_SUBMIT_RETRY_DELAY:STRING=5

//Path to a program.
CVSCOMMAND:FILEPATH=CVSCOMMAND-NOTFOUND

//Options passed to the cvs update command.
CVS_UPDATE_OPTIONS:STRING=-d -A -P

//Maximum time allowed before CTest will kill the test.
DART_TESTING_TIMEOUT:STRING=1500

//Value Computed by CMake
Eigen3_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/eigen/vtkeigen

//Value Computed by CMake
Eigen3_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/eigen/vtkeigen

//Additional URL templates for the ExternalData CMake script to
// look for testing data. E.g. file:///var/bigharddrive/%(algo)/%(hash)
ExternalData_URL_TEMPLATES:STRING=

FFMPEG_ROOT:PATH=c:/akit/mineview/src/ffmpeg

//FFMPEG's avcodec include directory
FFMPEG_avcodec_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's avcodec library
FFMPEG_avcodec_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/avcodec.lib

//FFMPEG's avdevice include directory
FFMPEG_avdevice_INCLUDE_DIR:PATH=FFMPEG_avdevice_INCLUDE_DIR-NOTFOUND

//FFMPEG's avdevice library
FFMPEG_avdevice_LIBRARY:FILEPATH=FFMPEG_avdevice_LIBRARY-NOTFOUND

//FFMPEG's avfilter include directory
FFMPEG_avfilter_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's avfilter library
FFMPEG_avfilter_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/avfilter.lib

//FFMPEG's avformat include directory
FFMPEG_avformat_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's avformat library
FFMPEG_avformat_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/avformat.lib

//FFMPEG's avresample include directory
FFMPEG_avresample_INCLUDE_DIR:PATH=FFMPEG_avresample_INCLUDE_DIR-NOTFOUND

//FFMPEG's avresample library
FFMPEG_avresample_LIBRARY:FILEPATH=FFMPEG_avresample_LIBRARY-NOTFOUND

//FFMPEG's avutil include directory
FFMPEG_avutil_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's avutil library
FFMPEG_avutil_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/avutil.lib

//FFMPEG's swresample include directory
FFMPEG_swresample_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's swresample library
FFMPEG_swresample_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/swresample.lib

//FFMPEG's swscale include directory
FFMPEG_swscale_INCLUDE_DIR:PATH=C:/akit/mineview/src/ffmpeg/include

//FFMPEG's swscale library
FFMPEG_swscale_LIBRARY:FILEPATH=C:/akit/mineview/src/ffmpeg/bin/swscale.lib

//Path to a program.
GITCOMMAND:FILEPATH=C:/Program Files/Git/cmd/git.exe

//Value Computed by CMake
HDF5_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/hdf5/vtkhdf5

//Value Computed by CMake
HDF5_HL_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/hdf5/vtkhdf5/hl

//Value Computed by CMake
HDF5_HL_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/hdf5/vtkhdf5/hl

//Value Computed by CMake
HDF5_HL_SRC_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/hdf5/vtkhdf5/hl/src

//Value Computed by CMake
HDF5_HL_SRC_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/hdf5/vtkhdf5/hl/src

//Value Computed by CMake
HDF5_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/hdf5/vtkhdf5

//Value Computed by CMake
HDF5_SRC_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/hdf5/vtkhdf5/src

//Value Computed by CMake
HDF5_SRC_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/hdf5/vtkhdf5/src

//Path to a program.
HGCOMMAND:FILEPATH=HGCOMMAND-NOTFOUND

//Command to build the project
MAKECOMMAND:STRING="C:\Program Files\CMake\bin\cmake.exe" --build . --config "${CTEST_CONFIGURATION_TYPE}"

//Path to the memory checking command, used for memory error detection.
MEMORYCHECK_COMMAND:FILEPATH=MEMORYCHECK_COMMAND-NOTFOUND

//File that contains suppressions for the memory checker
MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH=

//Path to a program.
NSIS_EXECUTABLE:FILEPATH=C:/Program Files (x86)/NSIS/NSIS.exe

//OpenGL library for win32
OPENGL_gl_LIBRARY:STRING=opengl32

//GLU library for win32
OPENGL_glu_LIBRARY:STRING=glu32

OpenVR_INCLUDE_DIR:PATH=C:/akit/openvr/headers

OpenVR_LIBRARY:FILEPATH=C:/akit/openvr/lib/win64/openvr_api.lib

//Path to a program.
P4COMMAND:FILEPATH=P4COMMAND-NOTFOUND

//Value Computed by CMake
PROJ4_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/libproj/vtklibproj

//Value Computed by CMake
PROJ4_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/libproj/vtklibproj

//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=C:/Python36/python.exe

//Path to a file.
RMANTREE:PATH=RMANTREE-NOTFOUND

//Path to scp command, used by CTest for submitting results to
// a Dart server
SCPCOMMAND:FILEPATH=C:/Windows/System32/OpenSSH/scp.exe

//Name of the computer/site where compile is being run
SITE:STRING=LYONESSE

//Path to the SLURM sbatch executable
SLURM_SBATCH_COMMAND:FILEPATH=SLURM_SBATCH_COMMAND-NOTFOUND

//Path to the SLURM srun executable
SLURM_SRUN_COMMAND:FILEPATH=SLURM_SRUN_COMMAND-NOTFOUND

//Path to a program.
SVNCOMMAND:FILEPATH=SVNCOMMAND-NOTFOUND

//Build all vtkObject derived classes with object factory new methods.
VTK_ALL_NEW_OBJECT_FACTORY:BOOL=OFF

//Enable additional optimizations for array iterators in Debug
// builds.
VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS:BOOL=OFF

//Build VTK for Android
VTK_ANDROID_BUILD:BOOL=OFF

//Value Computed by CMake
VTK_BINARY_DIR:STATIC=C:/akit/vtk/build

//Build all modules by default
VTK_BUILD_ALL_MODULES:BOOL=OFF

//If enabled, the test used to generate the vtkBlueObeliskDataInternal.h
// header will be built.
VTK_BUILD_BODR_DATA_GENERATOR:BOOL=OFF

//Build the VTK documentation
VTK_BUILD_DOCUMENTATION:BOOL=OFF

//Build VTK examples.
VTK_BUILD_EXAMPLES:BOOL=OFF

//Build module testing directories
VTK_BUILD_TESTING:STRING=WANT

//Exclude test data download from default 'all' target.
VTK_DATA_EXCLUDE_FROM_ALL:BOOL=OFF

//Local directory holding ExternalData objects in the layout %(algo)/%(hash).
VTK_DATA_STORE:PATH=C:/Users/aron.helser.KHQ/.ExternalData

//Build leak checking support into VTK.
VTK_DEBUG_LEAKS:BOOL=OFF

//EGL device (graphics card) index to use by default for EGL render
// windows.
VTK_DEFAULT_EGL_DEVICE_INDEX:STRING=0

//Use offscreen render window by default
VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN:BOOL=OFF

//Include array-of-structs vtkDataArray subclasses in dispatcher.
VTK_DISPATCH_AOS_ARRAYS:BOOL=ON

//Include struct-of-arrays vtkDataArray subclasses in dispatcher.
VTK_DISPATCH_SOA_ARRAYS:BOOL=OFF

//Include vtkTypedDataArray subclasses (e.g. old mapped arrays)
// in dispatcher.
VTK_DISPATCH_TYPED_ARRAYS:BOOL=OFF

//Suppress warnings from third-party libraries from showing on
// CDash
VTK_ENABLE_CDASH_THIRD_PARTY_WARNINGS:BOOL=OFF

//Enable kits compilation
VTK_ENABLE_KITS:BOOL=OFF

VTK_ENABLE_PYTHON:BOOL=ON

//Do not download source code or data from the network
VTK_FORBID_DOWNLOADS:BOOL=OFF

//Path to a program.
VTK_GHOSTSCRIPT_EXECUTABLE:FILEPATH=VTK_GHOSTSCRIPT_EXECUTABLE-NOTFOUND

//Location of the OpenGL extensions header file (glext.h).
VTK_GLEXT_FILE:FILEPATH=C:/akit/vtk/src/Utilities/ParseOGLExt/headers/glext.h

//Location of the GLX extensions header file (glxext.h).
VTK_GLXEXT_FILE:FILEPATH=C:/akit/vtk/src/Utilities/ParseOGLExt/headers/glxext.h

//Enable the Imaging group modules.
VTK_GROUP_ENABLE_Imaging:STRING=DEFAULT

//Enable the MPI group modules.
VTK_GROUP_ENABLE_MPI:STRING=DONT_WANT

//Enable the Qt group modules.
VTK_GROUP_ENABLE_Qt:STRING=DEFAULT

//Enable the Rendering group modules.
VTK_GROUP_ENABLE_Rendering:STRING=WANT

//Enable the StandAlone group modules.
VTK_GROUP_ENABLE_StandAlone:STRING=WANT

//Enable the Tk group modules.
VTK_GROUP_ENABLE_Tk:STRING=DEFAULT

//Enable the Views group modules.
VTK_GROUP_ENABLE_Views:STRING=DEFAULT

//Enable the Web group modules.
VTK_GROUP_ENABLE_Web:STRING=DEFAULT

//Build vtk.framework for iOS
VTK_IOS_BUILD:BOOL=OFF

//Remove all legacy code completely.
VTK_LEGACY_REMOVE:BOOL=ON

//Silence all legacy code messages.
VTK_LEGACY_SILENT:BOOL=OFF

//Max number of threads vtkMultiThreader will allocate.
VTK_MAX_THREADS:STRING=64

//Enable the VTK::AcceleratorsVTKm module. VTKm filters and algorithms
VTK_MODULE_ENABLE_VTK_AcceleratorsVTKm:STRING=DEFAULT

//Enable the VTK::ChartsCore module. Charts and plots
VTK_MODULE_ENABLE_VTK_ChartsCore:STRING=DEFAULT

//Enable the VTK::CommonColor module. Color palette and named color
// support classes
VTK_MODULE_ENABLE_VTK_CommonColor:STRING=DEFAULT

//Enable the VTK::CommonComputationalGeometry module. Parametric
// splines and curves
VTK_MODULE_ENABLE_VTK_CommonComputationalGeometry:STRING=DEFAULT

//Enable the VTK::CommonCore module. The base VTK library
VTK_MODULE_ENABLE_VTK_CommonCore:STRING=DEFAULT

//Enable the VTK::CommonDataModel module. Core data types
VTK_MODULE_ENABLE_VTK_CommonDataModel:STRING=DEFAULT

//Enable the VTK::CommonExecutionModel module. Core algorithms
// and execution
VTK_MODULE_ENABLE_VTK_CommonExecutionModel:STRING=DEFAULT

//Enable the VTK::CommonMath module. Linear algebra types
VTK_MODULE_ENABLE_VTK_CommonMath:STRING=DEFAULT

//Enable the VTK::CommonMisc module. Assorted utility classes
VTK_MODULE_ENABLE_VTK_CommonMisc:STRING=DEFAULT

//Enable the VTK::CommonSystem module. Filesystem and networking
// support
VTK_MODULE_ENABLE_VTK_CommonSystem:STRING=DEFAULT

//Enable the VTK::CommonTransforms module. Linear algebra transformations
VTK_MODULE_ENABLE_VTK_CommonTransforms:STRING=DEFAULT

//Enable the VTK::DICOMParser module. 
VTK_MODULE_ENABLE_VTK_DICOMParser:STRING=DEFAULT

//Enable the VTK::DomainsChemistry module. File readers and algorithms
// used in chemistry
VTK_MODULE_ENABLE_VTK_DomainsChemistry:STRING=DEFAULT

//Enable the VTK::DomainsChemistryOpenGL2 module. OpenGL support
// for chemistry data
VTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2:STRING=DEFAULT

//Enable the VTK::DomainsMicroscopy module. File readers for microscopy
// file formats
VTK_MODULE_ENABLE_VTK_DomainsMicroscopy:STRING=DEFAULT

//Enable the VTK::DomainsParallelChemistry module. Parallel versions
// of algorithms used in chemistry
VTK_MODULE_ENABLE_VTK_DomainsParallelChemistry:STRING=DEFAULT

//Enable the VTK::FiltersAMR module. Adaptive mesh refinement filters
// and algorithms
VTK_MODULE_ENABLE_VTK_FiltersAMR:STRING=DEFAULT

//Enable the VTK::FiltersCore module. Common filters for VTK data
// types
VTK_MODULE_ENABLE_VTK_FiltersCore:STRING=DEFAULT

//Enable the VTK::FiltersExtraction module. Filters for selecting
// subsets data
VTK_MODULE_ENABLE_VTK_FiltersExtraction:STRING=DEFAULT

//Enable the VTK::FiltersFlowPaths module. Filters and algorithms
// for streamlines
VTK_MODULE_ENABLE_VTK_FiltersFlowPaths:STRING=DEFAULT

//Enable the VTK::FiltersGeneral module. Filters for transforming
// data
VTK_MODULE_ENABLE_VTK_FiltersGeneral:STRING=DEFAULT

//Enable the VTK::FiltersGeneric module. Filters for selecting
// subsets of data at arbitrary points
VTK_MODULE_ENABLE_VTK_FiltersGeneric:STRING=DEFAULT

//Enable the VTK::FiltersGeometry module. Geometric transformation
// filters
VTK_MODULE_ENABLE_VTK_FiltersGeometry:STRING=DEFAULT

//Enable the VTK::FiltersHybrid module. 
VTK_MODULE_ENABLE_VTK_FiltersHybrid:STRING=DEFAULT

//Enable the VTK::FiltersHyperTree module. Hypertree filters and
// algorithms
VTK_MODULE_ENABLE_VTK_FiltersHyperTree:STRING=DEFAULT

//Enable the VTK::FiltersImaging module. Filters and algorithms
// for images
VTK_MODULE_ENABLE_VTK_FiltersImaging:STRING=DEFAULT

//Enable the VTK::FiltersModeling module. 
VTK_MODULE_ENABLE_VTK_FiltersModeling:STRING=DEFAULT

//Enable the VTK::FiltersOpenTurns module. 
VTK_MODULE_ENABLE_VTK_FiltersOpenTurns:STRING=DEFAULT

//Enable the VTK::FiltersParallel module. 
VTK_MODULE_ENABLE_VTK_FiltersParallel:STRING=DEFAULT

//Enable the VTK::FiltersParallelFlowPaths module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelFlowPaths:STRING=DEFAULT

//Enable the VTK::FiltersParallelGeometry module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelGeometry:STRING=DEFAULT

//Enable the VTK::FiltersParallelImaging module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelImaging:STRING=DEFAULT

//Enable the VTK::FiltersParallelMPI module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelMPI:STRING=DEFAULT

//Enable the VTK::FiltersParallelStatistics module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelStatistics:STRING=DEFAULT

//Enable the VTK::FiltersParallelVerdict module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelVerdict:STRING=DEFAULT

//Enable the VTK::FiltersPoints module. 
VTK_MODULE_ENABLE_VTK_FiltersPoints:STRING=DEFAULT

//Enable the VTK::FiltersProgrammable module. 
VTK_MODULE_ENABLE_VTK_FiltersProgrammable:STRING=DEFAULT

//Enable the VTK::FiltersReebGraph module. 
VTK_MODULE_ENABLE_VTK_FiltersReebGraph:STRING=DEFAULT

//Enable the VTK::FiltersSMP module. 
VTK_MODULE_ENABLE_VTK_FiltersSMP:STRING=DEFAULT

//Enable the VTK::FiltersSelection module. 
VTK_MODULE_ENABLE_VTK_FiltersSelection:STRING=DEFAULT

//Enable the VTK::FiltersSources module. 
VTK_MODULE_ENABLE_VTK_FiltersSources:STRING=DEFAULT

//Enable the VTK::FiltersStatistics module. 
VTK_MODULE_ENABLE_VTK_FiltersStatistics:STRING=DEFAULT

//Enable the VTK::FiltersTexture module. 
VTK_MODULE_ENABLE_VTK_FiltersTexture:STRING=DEFAULT

//Enable the VTK::FiltersTopology module. 
VTK_MODULE_ENABLE_VTK_FiltersTopology:STRING=DEFAULT

//Enable the VTK::FiltersVerdict module. 
VTK_MODULE_ENABLE_VTK_FiltersVerdict:STRING=DEFAULT

//Enable the VTK::GUISupportMFC module. 
VTK_MODULE_ENABLE_VTK_GUISupportMFC:STRING=DEFAULT

//Enable the VTK::GUISupportQt module. 
VTK_MODULE_ENABLE_VTK_GUISupportQt:STRING=DEFAULT

//Enable the VTK::GUISupportQtOpenGL module. 
VTK_MODULE_ENABLE_VTK_GUISupportQtOpenGL:STRING=DEFAULT

//Enable the VTK::GUISupportQtSQL module. 
VTK_MODULE_ENABLE_VTK_GUISupportQtSQL:STRING=DEFAULT

//Enable the VTK::GeovisCore module. 
VTK_MODULE_ENABLE_VTK_GeovisCore:STRING=DEFAULT

//Enable the VTK::GeovisGDAL module. 
VTK_MODULE_ENABLE_VTK_GeovisGDAL:STRING=DEFAULT

//Enable the VTK::IOADIOS module. 
VTK_MODULE_ENABLE_VTK_IOADIOS:STRING=DEFAULT

//Enable the VTK::IOAMR module. 
VTK_MODULE_ENABLE_VTK_IOAMR:STRING=DEFAULT

//Enable the VTK::IOAsynchronous module. 
VTK_MODULE_ENABLE_VTK_IOAsynchronous:STRING=DEFAULT

//Enable the VTK::IOCityGML module. 
VTK_MODULE_ENABLE_VTK_IOCityGML:STRING=DEFAULT

//Enable the VTK::IOCore module. 
VTK_MODULE_ENABLE_VTK_IOCore:STRING=DEFAULT

//Enable the VTK::IOEnSight module. 
VTK_MODULE_ENABLE_VTK_IOEnSight:STRING=DEFAULT

//Enable the VTK::IOExodus module. 
VTK_MODULE_ENABLE_VTK_IOExodus:STRING=DEFAULT

//Enable the VTK::IOExport module. 
VTK_MODULE_ENABLE_VTK_IOExport:STRING=DEFAULT

//Enable the VTK::IOExportGL2PS module. 
VTK_MODULE_ENABLE_VTK_IOExportGL2PS:STRING=DEFAULT

//Enable the VTK::IOExportPDF module. 
VTK_MODULE_ENABLE_VTK_IOExportPDF:STRING=DEFAULT

VTK_MODULE_ENABLE_VTK_IOFFMPEG:STRING=YES

//Enable the VTK::IOGDAL module. 
VTK_MODULE_ENABLE_VTK_IOGDAL:STRING=DEFAULT

//Enable the VTK::IOGeoJSON module. 
VTK_MODULE_ENABLE_VTK_IOGeoJSON:STRING=DEFAULT

//Enable the VTK::IOGeometry module. 
VTK_MODULE_ENABLE_VTK_IOGeometry:STRING=DEFAULT

//Enable the VTK::IOImage module. 
VTK_MODULE_ENABLE_VTK_IOImage:STRING=DEFAULT

//Enable the VTK::IOImport module. 
VTK_MODULE_ENABLE_VTK_IOImport:STRING=DEFAULT

//Enable the VTK::IOInfovis module. 
VTK_MODULE_ENABLE_VTK_IOInfovis:STRING=DEFAULT

//Enable the VTK::IOLAS module. 
VTK_MODULE_ENABLE_VTK_IOLAS:STRING=DEFAULT

//Enable the VTK::IOLSDyna module. 
VTK_MODULE_ENABLE_VTK_IOLSDyna:STRING=DEFAULT

//Enable the VTK::IOLegacy module. 
VTK_MODULE_ENABLE_VTK_IOLegacy:STRING=DEFAULT

//Enable the VTK::IOMINC module. 
VTK_MODULE_ENABLE_VTK_IOMINC:STRING=DEFAULT

//Enable the VTK::IOMPIImage module. 
VTK_MODULE_ENABLE_VTK_IOMPIImage:STRING=DEFAULT

//Enable the VTK::IOMotionFX module. 
VTK_MODULE_ENABLE_VTK_IOMotionFX:STRING=DEFAULT

//Enable the VTK::IOMovie module. 
VTK_MODULE_ENABLE_VTK_IOMovie:STRING=DEFAULT

//Enable the VTK::IOMySQL module. 
VTK_MODULE_ENABLE_VTK_IOMySQL:STRING=DEFAULT

//Enable the VTK::IONetCDF module. 
VTK_MODULE_ENABLE_VTK_IONetCDF:STRING=DEFAULT

//Enable the VTK::IOODBC module. 
VTK_MODULE_ENABLE_VTK_IOODBC:STRING=DEFAULT

//Enable the VTK::IOOggTheora module. 
VTK_MODULE_ENABLE_VTK_IOOggTheora:STRING=DEFAULT

//Enable the VTK::IOPDAL module. 
VTK_MODULE_ENABLE_VTK_IOPDAL:STRING=DEFAULT

//Enable the VTK::IOPLY module. 
VTK_MODULE_ENABLE_VTK_IOPLY:STRING=DEFAULT

//Enable the VTK::IOParallel module. 
VTK_MODULE_ENABLE_VTK_IOParallel:STRING=DEFAULT

//Enable the VTK::IOParallelExodus module. 
VTK_MODULE_ENABLE_VTK_IOParallelExodus:STRING=DEFAULT

//Enable the VTK::IOParallelLSDyna module. 
VTK_MODULE_ENABLE_VTK_IOParallelLSDyna:STRING=DEFAULT

//Enable the VTK::IOParallelNetCDF module. 
VTK_MODULE_ENABLE_VTK_IOParallelNetCDF:STRING=DEFAULT

//Enable the VTK::IOParallelXML module. 
VTK_MODULE_ENABLE_VTK_IOParallelXML:STRING=DEFAULT

//Enable the VTK::IOParallelXdmf3 module. 
VTK_MODULE_ENABLE_VTK_IOParallelXdmf3:STRING=DEFAULT

//Enable the VTK::IOPostgreSQL module. 
VTK_MODULE_ENABLE_VTK_IOPostgreSQL:STRING=DEFAULT

//Enable the VTK::IOSQL module. 
VTK_MODULE_ENABLE_VTK_IOSQL:STRING=DEFAULT

//Enable the VTK::IOSegY module. 
VTK_MODULE_ENABLE_VTK_IOSegY:STRING=DEFAULT

//Enable the VTK::IOTRUCHAS module. 
VTK_MODULE_ENABLE_VTK_IOTRUCHAS:STRING=DEFAULT

//Enable the VTK::IOTecplotTable module. 
VTK_MODULE_ENABLE_VTK_IOTecplotTable:STRING=DEFAULT

//Enable the VTK::IOVPIC module. 
VTK_MODULE_ENABLE_VTK_IOVPIC:STRING=DEFAULT

//Enable the VTK::IOVeraOut module. 
VTK_MODULE_ENABLE_VTK_IOVeraOut:STRING=DEFAULT

//Enable the VTK::IOVideo module. 
VTK_MODULE_ENABLE_VTK_IOVideo:STRING=DEFAULT

//Enable the VTK::IOXML module. 
VTK_MODULE_ENABLE_VTK_IOXML:STRING=DEFAULT

//Enable the VTK::IOXMLParser module. 
VTK_MODULE_ENABLE_VTK_IOXMLParser:STRING=DEFAULT

//Enable the VTK::IOXdmf2 module. 
VTK_MODULE_ENABLE_VTK_IOXdmf2:STRING=DEFAULT

//Enable the VTK::IOXdmf3 module. 
VTK_MODULE_ENABLE_VTK_IOXdmf3:STRING=DEFAULT

//Enable the VTK::ImagingColor module. 
VTK_MODULE_ENABLE_VTK_ImagingColor:STRING=DEFAULT

//Enable the VTK::ImagingCore module. 
VTK_MODULE_ENABLE_VTK_ImagingCore:STRING=DEFAULT

//Enable the VTK::ImagingFourier module. 
VTK_MODULE_ENABLE_VTK_ImagingFourier:STRING=DEFAULT

//Enable the VTK::ImagingGeneral module. 
VTK_MODULE_ENABLE_VTK_ImagingGeneral:STRING=DEFAULT

//Enable the VTK::ImagingHybrid module. 
VTK_MODULE_ENABLE_VTK_ImagingHybrid:STRING=DEFAULT

//Enable the VTK::ImagingMath module. 
VTK_MODULE_ENABLE_VTK_ImagingMath:STRING=DEFAULT

//Enable the VTK::ImagingMorphological module. 
VTK_MODULE_ENABLE_VTK_ImagingMorphological:STRING=DEFAULT

//Enable the VTK::ImagingOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_ImagingOpenGL2:STRING=DEFAULT

//Enable the VTK::ImagingSources module. 
VTK_MODULE_ENABLE_VTK_ImagingSources:STRING=DEFAULT

//Enable the VTK::ImagingStatistics module. 
VTK_MODULE_ENABLE_VTK_ImagingStatistics:STRING=DEFAULT

//Enable the VTK::ImagingStencil module. 
VTK_MODULE_ENABLE_VTK_ImagingStencil:STRING=DEFAULT

//Enable the VTK::InfovisBoost module. 
VTK_MODULE_ENABLE_VTK_InfovisBoost:STRING=DEFAULT

//Enable the VTK::InfovisBoostGraphAlgorithms module. 
VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms:STRING=DEFAULT

//Enable the VTK::InfovisCore module. 
VTK_MODULE_ENABLE_VTK_InfovisCore:STRING=DEFAULT

//Enable the VTK::InfovisLayout module. 
VTK_MODULE_ENABLE_VTK_InfovisLayout:STRING=DEFAULT

//Enable the VTK::InteractionImage module. 
VTK_MODULE_ENABLE_VTK_InteractionImage:STRING=DEFAULT

//Enable the VTK::InteractionStyle module. 
VTK_MODULE_ENABLE_VTK_InteractionStyle:STRING=DEFAULT

//Enable the VTK::InteractionWidgets module. 
VTK_MODULE_ENABLE_VTK_InteractionWidgets:STRING=DEFAULT

//Enable the VTK::ParallelCore module. 
VTK_MODULE_ENABLE_VTK_ParallelCore:STRING=DEFAULT

//Enable the VTK::ParallelMPI module. 
VTK_MODULE_ENABLE_VTK_ParallelMPI:STRING=DEFAULT

//Enable the VTK::PythonInterpreter module. 
VTK_MODULE_ENABLE_VTK_PythonInterpreter:STRING=DEFAULT

//Enable the VTK::RenderingAnnotation module. 
VTK_MODULE_ENABLE_VTK_RenderingAnnotation:STRING=DEFAULT

//Enable the VTK::RenderingContext2D module. 
VTK_MODULE_ENABLE_VTK_RenderingContext2D:STRING=DEFAULT

//Enable the VTK::RenderingContextOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2:STRING=DEFAULT

//Enable the VTK::RenderingCore module. 
VTK_MODULE_ENABLE_VTK_RenderingCore:STRING=DEFAULT

//Enable the VTK::RenderingExternal module. 
VTK_MODULE_ENABLE_VTK_RenderingExternal:STRING=DEFAULT

//Enable the VTK::RenderingFreeType module. 
VTK_MODULE_ENABLE_VTK_RenderingFreeType:STRING=DEFAULT

//Enable the VTK::RenderingFreeTypeFontConfig module. 
VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig:STRING=DEFAULT

//Enable the VTK::RenderingGL2PSOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2:STRING=DEFAULT

//Enable the VTK::RenderingImage module. 
VTK_MODULE_ENABLE_VTK_RenderingImage:STRING=DEFAULT

//Enable the VTK::RenderingLICOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_RenderingLICOpenGL2:STRING=DEFAULT

//Enable the VTK::RenderingLOD module. 
VTK_MODULE_ENABLE_VTK_RenderingLOD:STRING=DEFAULT

//Enable the VTK::RenderingLabel module. 
VTK_MODULE_ENABLE_VTK_RenderingLabel:STRING=DEFAULT

//Enable the VTK::RenderingMatplotlib module. 
VTK_MODULE_ENABLE_VTK_RenderingMatplotlib:STRING=DEFAULT

//Enable the VTK::RenderingOSPRay module. 
VTK_MODULE_ENABLE_VTK_RenderingOSPRay:STRING=DEFAULT

//Enable the VTK::RenderingOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_RenderingOpenGL2:STRING=DEFAULT

VTK_MODULE_ENABLE_VTK_RenderingOpenVR:STRING=YES

//Enable the VTK::RenderingOptiX module. 
VTK_MODULE_ENABLE_VTK_RenderingOptiX:STRING=DEFAULT

//Enable the VTK::RenderingParallel module. 
VTK_MODULE_ENABLE_VTK_RenderingParallel:STRING=DEFAULT

//Enable the VTK::RenderingParallelLIC module. 
VTK_MODULE_ENABLE_VTK_RenderingParallelLIC:STRING=DEFAULT

//Enable the VTK::RenderingQt module. 
VTK_MODULE_ENABLE_VTK_RenderingQt:STRING=DEFAULT

//Enable the VTK::RenderingSceneGraph module. 
VTK_MODULE_ENABLE_VTK_RenderingSceneGraph:STRING=DEFAULT

//Enable the VTK::RenderingVolume module. 
VTK_MODULE_ENABLE_VTK_RenderingVolume:STRING=DEFAULT

//Enable the VTK::RenderingVolumeAMR module. 
VTK_MODULE_ENABLE_VTK_RenderingVolumeAMR:STRING=DEFAULT

//Enable the VTK::RenderingVolumeOpenGL2 module. 
VTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2:STRING=DEFAULT

//Enable the VTK::TestingCore module. 
VTK_MODULE_ENABLE_VTK_TestingCore:STRING=DEFAULT

//Enable the VTK::TestingGenericBridge module. 
VTK_MODULE_ENABLE_VTK_TestingGenericBridge:STRING=DEFAULT

//Enable the VTK::TestingIOSQL module. 
VTK_MODULE_ENABLE_VTK_TestingIOSQL:STRING=DEFAULT

//Enable the VTK::TestingRendering module. 
VTK_MODULE_ENABLE_VTK_TestingRendering:STRING=DEFAULT

//Enable the VTK::UtilitiesBenchmarks module. 
VTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks:STRING=DEFAULT

//Enable the VTK::ViewsContext2D module. 
VTK_MODULE_ENABLE_VTK_ViewsContext2D:STRING=DEFAULT

//Enable the VTK::ViewsCore module. 
VTK_MODULE_ENABLE_VTK_ViewsCore:STRING=DEFAULT

//Enable the VTK::ViewsInfovis module. 
VTK_MODULE_ENABLE_VTK_ViewsInfovis:STRING=DEFAULT

//Enable the VTK::ViewsQt module. 
VTK_MODULE_ENABLE_VTK_ViewsQt:STRING=DEFAULT

//Enable the VTK::WebCore module. 
VTK_MODULE_ENABLE_VTK_WebCore:STRING=DEFAULT

//Enable the VTK::WebGLExporter module. 
VTK_MODULE_ENABLE_VTK_WebGLExporter:STRING=DEFAULT

//Enable the VTK::WrappingPythonCore module. 
VTK_MODULE_ENABLE_VTK_WrappingPythonCore:STRING=DEFAULT

//Enable the VTK::WrappingTools module. 
VTK_MODULE_ENABLE_VTK_WrappingTools:STRING=DEFAULT

//Enable the VTK::diy2 module. 
VTK_MODULE_ENABLE_VTK_diy2:STRING=DEFAULT

//Enable the VTK::doubleconversion module. 
VTK_MODULE_ENABLE_VTK_doubleconversion:STRING=DEFAULT

//Enable the VTK::eigen module. 
VTK_MODULE_ENABLE_VTK_eigen:STRING=DEFAULT

//Enable the VTK::exodusII module. 
VTK_MODULE_ENABLE_VTK_exodusII:STRING=DEFAULT

//Enable the VTK::expat module. 
VTK_MODULE_ENABLE_VTK_expat:STRING=DEFAULT

//Enable the VTK::freetype module. 
VTK_MODULE_ENABLE_VTK_freetype:STRING=DEFAULT

//Enable the VTK::gl2ps module. 
VTK_MODULE_ENABLE_VTK_gl2ps:STRING=DEFAULT

//Enable the VTK::glew module. 
VTK_MODULE_ENABLE_VTK_glew:STRING=DEFAULT

//Enable the VTK::hdf5 module. 
VTK_MODULE_ENABLE_VTK_hdf5:STRING=DEFAULT

//Enable the VTK::jpeg module. 
VTK_MODULE_ENABLE_VTK_jpeg:STRING=DEFAULT

//Enable the VTK::jsoncpp module. 
VTK_MODULE_ENABLE_VTK_jsoncpp:STRING=DEFAULT

//Enable the VTK::kissfft module. 
VTK_MODULE_ENABLE_VTK_kissfft:STRING=DEFAULT

//Enable the VTK::kwiml module. 
VTK_MODULE_ENABLE_VTK_kwiml:STRING=DEFAULT

//Enable the VTK::libharu module. 
VTK_MODULE_ENABLE_VTK_libharu:STRING=DEFAULT

//Enable the VTK::libproj module. 
VTK_MODULE_ENABLE_VTK_libproj:STRING=DEFAULT

//Enable the VTK::libxml2 module. 
VTK_MODULE_ENABLE_VTK_libxml2:STRING=DEFAULT

//Enable the VTK::lz4 module. 
VTK_MODULE_ENABLE_VTK_lz4:STRING=DEFAULT

//Enable the VTK::lzma module. 
VTK_MODULE_ENABLE_VTK_lzma:STRING=DEFAULT

//Enable the VTK::metaio module. 
VTK_MODULE_ENABLE_VTK_metaio:STRING=DEFAULT

//Enable the VTK::mpi4py module. 
VTK_MODULE_ENABLE_VTK_mpi4py:STRING=DEFAULT

//Enable the VTK::netcdf module. 
VTK_MODULE_ENABLE_VTK_netcdf:STRING=DEFAULT

//Enable the VTK::octree module. 
VTK_MODULE_ENABLE_VTK_octree:STRING=DEFAULT

//Enable the VTK::ogg module. 
VTK_MODULE_ENABLE_VTK_ogg:STRING=DEFAULT

//Enable the VTK::opengl module. 
VTK_MODULE_ENABLE_VTK_opengl:STRING=DEFAULT

//Enable the VTK::pegtl module. 
VTK_MODULE_ENABLE_VTK_pegtl:STRING=DEFAULT

//Enable the VTK::png module. 
VTK_MODULE_ENABLE_VTK_png:STRING=DEFAULT

//Enable the VTK::pugixml module. 
VTK_MODULE_ENABLE_VTK_pugixml:STRING=DEFAULT

//Enable the VTK::sqlite module. 
VTK_MODULE_ENABLE_VTK_sqlite:STRING=DEFAULT

//Enable the VTK::theora module. 
VTK_MODULE_ENABLE_VTK_theora:STRING=DEFAULT

//Enable the VTK::tiff module. 
VTK_MODULE_ENABLE_VTK_tiff:STRING=DEFAULT

//Enable the VTK::utf8 module. 
VTK_MODULE_ENABLE_VTK_utf8:STRING=DEFAULT

//Enable the VTK::verdict module. 
VTK_MODULE_ENABLE_VTK_verdict:STRING=DEFAULT

//Enable the VTK::vpic module. 
VTK_MODULE_ENABLE_VTK_vpic:STRING=DEFAULT

//Enable the VTK::vtkm module. 
VTK_MODULE_ENABLE_VTK_vtkm:STRING=DEFAULT

//Enable the VTK::vtksys module. 
VTK_MODULE_ENABLE_VTK_vtksys:STRING=DEFAULT

//Enable the VTK::xdmf2 module. 
VTK_MODULE_ENABLE_VTK_xdmf2:STRING=DEFAULT

//Enable the VTK::xdmf3 module. 
VTK_MODULE_ENABLE_VTK_xdmf3:STRING=DEFAULT

//Enable the VTK::zfp module. 
VTK_MODULE_ENABLE_VTK_zfp:STRING=DEFAULT

//Enable the VTK::zlib module. 
VTK_MODULE_ENABLE_VTK_zlib:STRING=DEFAULT

//Use externally provided VTK::doubleconversion
VTK_MODULE_USE_EXTERNAL_VTK_doubleconversion:BOOL=OFF

//Use externally provided VTK::eigen
VTK_MODULE_USE_EXTERNAL_VTK_eigen:BOOL=OFF

//Use externally provided VTK::expat
VTK_MODULE_USE_EXTERNAL_VTK_expat:BOOL=OFF

//Use externally provided VTK::freetype
VTK_MODULE_USE_EXTERNAL_VTK_freetype:BOOL=OFF

//Use externally provided VTK::gl2ps
VTK_MODULE_USE_EXTERNAL_VTK_gl2ps:BOOL=OFF

//Use externally provided VTK::glew
VTK_MODULE_USE_EXTERNAL_VTK_glew:BOOL=OFF

//Use externally provided VTK::hdf5
VTK_MODULE_USE_EXTERNAL_VTK_hdf5:BOOL=OFF

//Use externally provided VTK::jpeg
VTK_MODULE_USE_EXTERNAL_VTK_jpeg:BOOL=OFF

//Use externally provided VTK::jsoncpp
VTK_MODULE_USE_EXTERNAL_VTK_jsoncpp:BOOL=OFF

//Use externally provided VTK::libharu
VTK_MODULE_USE_EXTERNAL_VTK_libharu:BOOL=OFF

//Use externally provided VTK::libproj
VTK_MODULE_USE_EXTERNAL_VTK_libproj:BOOL=OFF

//Use externally provided VTK::libxml2
VTK_MODULE_USE_EXTERNAL_VTK_libxml2:BOOL=OFF

//Use externally provided VTK::lz4
VTK_MODULE_USE_EXTERNAL_VTK_lz4:BOOL=OFF

//Use externally provided VTK::lzma
VTK_MODULE_USE_EXTERNAL_VTK_lzma:BOOL=OFF

//Use externally provided VTK::netcdf
VTK_MODULE_USE_EXTERNAL_VTK_netcdf:BOOL=OFF

//Use externally provided VTK::ogg
VTK_MODULE_USE_EXTERNAL_VTK_ogg:BOOL=OFF

//Use externally provided VTK::png
VTK_MODULE_USE_EXTERNAL_VTK_png:BOOL=OFF

//Use externally provided VTK::sqlite
VTK_MODULE_USE_EXTERNAL_VTK_sqlite:BOOL=OFF

//Use externally provided VTK::theora
VTK_MODULE_USE_EXTERNAL_VTK_theora:BOOL=OFF

//Use externally provided VTK::tiff
VTK_MODULE_USE_EXTERNAL_VTK_tiff:BOOL=OFF

//Use externally provided VTK::zlib
VTK_MODULE_USE_EXTERNAL_VTK_zlib:BOOL=OFF

//Enable debugging annotations in the OpenGL command stream.
VTK_OPENGL_ENABLE_STREAM_ANNOTATIONS:BOOL=OFF

//The OpenGL library being used supports EGL
VTK_OPENGL_HAS_EGL:BOOL=OFF

//The OpenGL library being used supports offscreen Mesa (OSMesa)
VTK_OPENGL_HAS_OSMESA:BOOL=OFF

//Use the OpenGL ES API
VTK_OPENGL_USE_GLES:BOOL=OFF

VTK_PYTHON_VERSION:STRING=3

//Do not embed hard-coded paths into the install
VTK_RELOCATABLE_INSTALL:BOOL=ON

//Enable OpenGL error check and report
VTK_REPORT_OPENGL_ERRORS:BOOL=ON

//Enable OpenGL error check and reporting in non-debug builds.
VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS:BOOL=OFF

//Which multi-threaded parallelism implementation to use. Options
// are Sequential, OpenMP or TBB
VTK_SMP_IMPLEMENTATION_TYPE:STRING=Sequential

//Value Computed by CMake
VTK_SOURCE_DIR:STATIC=C:/akit/vtk/src

//Build VTK with 64 bit ids
VTK_USE_64BIT_IDS:BOOL=ON

//Use external copies of third party libraries by default
VTK_USE_EXTERNAL:BOOL=OFF

//Enable tests requiring "large" data
VTK_USE_LARGE_DATA:BOOL=OFF

//Support MPI
VTK_USE_MPI:BOOL=OFF

//Use delay loading for OpenGL
VTK_USE_OPENGL_DELAYED_LOAD:BOOL=OFF

//Enable using Video for Windows (vfw32) for video input and output.
VTK_USE_VIDEO_FOR_WINDOWS:BOOL=ON

//Use X for VTK render windows
VTK_USE_X:BOOL=OFF

//If enabled, vtkArrayDispatch will print a warning when a dispatch
// fails.
VTK_WARN_ON_DISPATCH_FAILURE:BOOL=OFF

//Location of the WGL extensions header file (wglext.h).
VTK_WGLEXT_FILE:FILEPATH=C:/akit/vtk/src/Utilities/ParseOGLExt/headers/wglext.h

//Path to a program.
VTK_WKHTMLTOIMAGE_EXECUTABLE:FILEPATH=VTK_WKHTMLTOIMAGE_EXECUTABLE-NOTFOUND

//Should VTK Java wrapping be built?
VTK_WRAP_JAVA:BOOL=OFF

//Should VTK Python wrapping be built?
VTK_WRAP_PYTHON:BOOL=OFF

//Path to a program.
WIX_EXECUTABLE:FILEPATH=WIX_EXECUTABLE-NOTFOUND

//Value Computed by CMake
libharu_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/libharu/vtklibharu

//Value Computed by CMake
libharu_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/libharu/vtklibharu

//Value Computed by CMake
libogg_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/ogg/vtkogg

//Value Computed by CMake
libogg_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/ogg/vtkogg

//Value Computed by CMake
pugixml_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/pugixml/vtkpugixml

//Value Computed by CMake
pugixml_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/pugixml/vtkpugixml

//Value Computed by CMake
tiff_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/tiff/vtktiff

//Value Computed by CMake
tiff_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/tiff/vtktiff

//Value Computed by CMake
verdict_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/verdict/vtkverdict

//Value Computed by CMake
verdict_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/verdict/vtkverdict

//Value Computed by CMake
vtkmetaio_BINARY_DIR:STATIC=C:/akit/vtk/build/Utilities/MetaIO/vtkmetaio

//Value Computed by CMake
vtkmetaio_SOURCE_DIR:STATIC=C:/akit/vtk/src/Utilities/MetaIO/vtkmetaio

//Value Computed by CMake
vtksys_BINARY_DIR:STATIC=C:/akit/vtk/build/Utilities/KWSys/vtksys

//Dependencies for the target
vtksys_LIB_DEPENDS:STATIC=general;ws2_32;general;Psapi;

//Value Computed by CMake
vtksys_SOURCE_DIR:STATIC=C:/akit/vtk/src/Utilities/KWSys/vtksys

//Value Computed by CMake
zlib_BINARY_DIR:STATIC=C:/akit/vtk/build/ThirdParty/zlib/vtkzlib

//Value Computed by CMake
zlib_SOURCE_DIR:STATIC=C:/akit/vtk/src/ThirdParty/zlib/vtkzlib


########################
# INTERNAL cache entries
########################

//ADVANCED property for variable: BZRCOMMAND
BZRCOMMAND-ADVANCED:INTERNAL=1
//This is the directory where this CMakeCache.txt was created
CMAKE_CACHEFILE_DIR:INTERNAL=c:/akit/vtk/build
//Major version of cmake used to create the current loaded cache
CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3
//Minor version of cmake used to create the current loaded cache
CMAKE_CACHE_MINOR_VERSION:INTERNAL=13
//Patch version of cmake used to create the current loaded cache
CMAKE_CACHE_PATCH_VERSION:INTERNAL=2
//Path to CMake executable.
CMAKE_COMMAND:INTERNAL=C:/Program Files/CMake/bin/cmake.exe
//Path to cpack program executable.
CMAKE_CPACK_COMMAND:INTERNAL=C:/Program Files/CMake/bin/cpack.exe
//ADVANCED property for variable: CMAKE_CTEST_COMMAND
CMAKE_CTEST_COMMAND-ADVANCED:INTERNAL=1
//Path to ctest program executable.
CMAKE_CTEST_COMMAND:INTERNAL=C:/Program Files/CMake/bin/ctest.exe
//ADVANCED property for variable: CMAKE_CXX_COMPILER
CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS
CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_CXX_STANDARD_LIBRARIES
CMAKE_CXX_STANDARD_LIBRARIES-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_COMPILER
CMAKE_C_COMPILER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_STANDARD_LIBRARIES
CMAKE_C_STANDARD_LIBRARIES-ADVANCED:INTERNAL=1
//Executable file format
CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE
CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_EXPORT_COMPILE_COMMANDS
CMAKE_EXPORT_COMPILE_COMMANDS-ADVANCED:INTERNAL=1
//Name of external makefile project generator.
CMAKE_EXTRA_GENERATOR:INTERNAL=
//Name of generator.
CMAKE_GENERATOR:INTERNAL=Ninja
//Generator instance identifier.
CMAKE_GENERATOR_INSTANCE:INTERNAL=
//Name of generator platform.
CMAKE_GENERATOR_PLATFORM:INTERNAL=
//Name of generator toolset.
CMAKE_GENERATOR_TOOLSET:INTERNAL=
//Have include pthread.h
CMAKE_HAVE_PTHREAD_H:INTERNAL=
//Source directory with the top level CMakeLists.txt file for this
// project
CMAKE_HOME_DIRECTORY:INTERNAL=C:/akit/vtk/src
//ADVANCED property for variable: CMAKE_INSTALL_BINDIR
CMAKE_INSTALL_BINDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_DATADIR
CMAKE_INSTALL_DATADIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_DATAROOTDIR
CMAKE_INSTALL_DATAROOTDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_DOCDIR
CMAKE_INSTALL_DOCDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_INCLUDEDIR
CMAKE_INSTALL_INCLUDEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_INFODIR
CMAKE_INSTALL_INFODIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_LIBDIR
CMAKE_INSTALL_LIBDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_LIBEXECDIR
CMAKE_INSTALL_LIBEXECDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_LOCALEDIR
CMAKE_INSTALL_LOCALEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_LOCALSTATEDIR
CMAKE_INSTALL_LOCALSTATEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_MANDIR
CMAKE_INSTALL_MANDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_OLDINCLUDEDIR
CMAKE_INSTALL_OLDINCLUDEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_RUNSTATEDIR
CMAKE_INSTALL_RUNSTATEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_SBINDIR
CMAKE_INSTALL_SBINDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_SHAREDSTATEDIR
CMAKE_INSTALL_SHAREDSTATEDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_INSTALL_SYSCONFDIR
CMAKE_INSTALL_SYSCONFDIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_LINKER
CMAKE_LINKER-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MAKE_PROGRAM
CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG
CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE
CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//number of local generators
CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=324
//Platform information initialized
CMAKE_PLATFORM_INFO_INITIALIZED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_COMPILER
CMAKE_RC_COMPILER-ADVANCED:INTERNAL=1
CMAKE_RC_COMPILER_WORKS:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_FLAGS
CMAKE_RC_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_FLAGS_DEBUG
CMAKE_RC_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_FLAGS_MINSIZEREL
CMAKE_RC_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_FLAGS_RELEASE
CMAKE_RC_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_RC_FLAGS_RELWITHDEBINFO
CMAKE_RC_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//Test Support for 64 bit file systems
CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=
//Path to CMake installation.
CMAKE_ROOT:INTERNAL=C:/Program Files/CMake/share/cmake-3.13
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG
CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE
CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(unsigned short)
CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=2
//ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH
CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//Test COMPILER_HAS_DEPRECATED
COMPILER_HAS_DEPRECATED:INTERNAL=1
//Test COMPILER_HAS_DEPRECATED_ATTR
COMPILER_HAS_DEPRECATED_ATTR:INTERNAL=
//Test COMPILER_SUPPORT_OPENMP
COMPILER_SUPPORT_OPENMP:INTERNAL=1
//ADVANCED property for variable: COVERAGE_COMMAND
COVERAGE_COMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: COVERAGE_EXTRA_FLAGS
COVERAGE_EXTRA_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CTEST_SUBMIT_RETRY_COUNT
CTEST_SUBMIT_RETRY_COUNT-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CTEST_SUBMIT_RETRY_DELAY
CTEST_SUBMIT_RETRY_DELAY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CVSCOMMAND
CVSCOMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CVS_UPDATE_OPTIONS
CVS_UPDATE_OPTIONS-ADVANCED:INTERNAL=1
//Test C_HAS_inline
C_HAS_inline:INTERNAL=1
//ADVANCED property for variable: DART_TESTING_TIMEOUT
DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1
//ADVANCED property for variable: ExternalData_URL_TEMPLATES
ExternalData_URL_TEMPLATES-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avcodec_INCLUDE_DIR
FFMPEG_avcodec_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avcodec_LIBRARY
FFMPEG_avcodec_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avdevice_INCLUDE_DIR
FFMPEG_avdevice_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avdevice_LIBRARY
FFMPEG_avdevice_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avfilter_INCLUDE_DIR
FFMPEG_avfilter_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avfilter_LIBRARY
FFMPEG_avfilter_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avformat_INCLUDE_DIR
FFMPEG_avformat_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avformat_LIBRARY
FFMPEG_avformat_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avresample_INCLUDE_DIR
FFMPEG_avresample_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avresample_LIBRARY
FFMPEG_avresample_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avutil_INCLUDE_DIR
FFMPEG_avutil_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_avutil_LIBRARY
FFMPEG_avutil_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_swresample_INCLUDE_DIR
FFMPEG_swresample_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_swresample_LIBRARY
FFMPEG_swresample_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_swscale_INCLUDE_DIR
FFMPEG_swscale_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: FFMPEG_swscale_LIBRARY
FFMPEG_swscale_LIBRARY-ADVANCED:INTERNAL=1
//Details about finding FFMPEG
FIND_PACKAGE_MESSAGE_DETAILS_FFMPEG:INTERNAL=[C:/akit/mineview/src/ffmpeg/include][C:/akit/mineview/src/ffmpeg/bin/avformat.lib;C:/akit/mineview/src/ffmpeg/bin/avcodec.lib;C:/akit/mineview/src/ffmpeg/bin/avutil.lib;C:/akit/mineview/src/ffmpeg/bin/swscale.lib][cfound components:  avformat avcodec avutil swscale ][v4.0.2(2.3.3)]
//Details about finding OpenGL
FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[opengl32][cfound components:  OpenGL ][v()]
//Details about finding OpenVR
FIND_PACKAGE_MESSAGE_DETAILS_OpenVR:INTERNAL=[C:/akit/openvr/lib/win64/openvr_api.lib][C:/akit/openvr/headers][v()]
//Details about finding Threads
FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()]
//Test FLAG_NO_STRICT_ALIASING
FLAG_NO_STRICT_ALIASING:INTERNAL=
//ADVANCED property for variable: GITCOMMAND
GITCOMMAND-ADVANCED:INTERNAL=1
//Have symbol H5Pset_all_coll_metadata_ops
H5PSET_ALL_COLL_METADATA_OPS:INTERNAL=
//Have function alarm
H5_HAVE_ALARM:INTERNAL=
//Have function asprintf
H5_HAVE_ASPRINTF:INTERNAL=
//Have function difftime
H5_HAVE_DIFFTIME:INTERNAL=1
//Have includes windows.h;sys/stat.h;sys/types.h;dirent.h
H5_HAVE_DIRENT_H:INTERNAL=
//Have includes windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h;winsock2.h;dlfcn.h
H5_HAVE_DLFCN_H:INTERNAL=
//Have function fcntl
H5_HAVE_FCNTL:INTERNAL=
//Have includes windows.h;sys/stat.h;sys/types.h;features.h
H5_HAVE_FEATURES_H:INTERNAL=
//Have function flock
H5_HAVE_FLOCK:INTERNAL=
//Have function fork
H5_HAVE_FORK:INTERNAL=
//Have function frexpf
H5_HAVE_FREXPF:INTERNAL=
//Have function frexpl
H5_HAVE_FREXPL:INTERNAL=
//Have function getrusage
H5_HAVE_GETRUSAGE:INTERNAL=
//Other test 
H5_HAVE_INLINE:INTERNAL=1
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h;winsock2.h;inttypes.h
H5_HAVE_INTTYPES_H:INTERNAL=1
//Test InitOnceExecuteOnce
H5_HAVE_IOEO:INTERNAL=1
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h
H5_HAVE_IO_H:INTERNAL=1
//Have includes windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;mach/mach_time.h
H5_HAVE_MACH_MACH_TIME_H:INTERNAL=
//Have symbol sigsetjmp
H5_HAVE_MACRO_SIGSETJMP:INTERNAL=
//Have includes windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h;winsock2.h;pthread.h
H5_HAVE_PTHREAD_H:INTERNAL=
//Have function random
H5_HAVE_RANDOM:INTERNAL=
//Have function rand_r
H5_HAVE_RAND_R:INTERNAL=
//Have function setjmp
H5_HAVE_SETJMP:INTERNAL=1
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h
H5_HAVE_SETJMP_H:INTERNAL=1
//Have function setsysinfo
H5_HAVE_SETSYSINFO:INTERNAL=
//Have function siglongjmp
H5_HAVE_SIGLONGJMP:INTERNAL=
//Have function signal
H5_HAVE_SIGNAL:INTERNAL=1
//Have function sigprocmask
H5_HAVE_SIGPROCMASK:INTERNAL=
//Have function sigsetjmp
H5_HAVE_SIGSETJMP:INTERNAL=
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h;winsock2.h;inttypes.h;stdbool.h
H5_HAVE_STDBOOL_H:INTERNAL=1
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h
H5_HAVE_STDINT_H:INTERNAL=1
//Have function strtoll
H5_HAVE_STRTOLL:INTERNAL=1
//Have function strtoull
H5_HAVE_STRTOULL:INTERNAL=1
//Have function symlink
H5_HAVE_SYMLINK:INTERNAL=
//Have includes windows.h;sys/file.h
H5_HAVE_SYS_FILE_H:INTERNAL=
//Have includes windows.h;sys/ioctl.h
H5_HAVE_SYS_IOCTL_H:INTERNAL=
//Have includes windows.h;sys/resource.h
H5_HAVE_SYS_RESOURCE_H:INTERNAL=
//Have includes windows.h;sys/stat.h;sys/time.h
H5_HAVE_SYS_TIME_H:INTERNAL=
//Have function tmpfile
H5_HAVE_TMPFILE:INTERNAL=1
//Have includes windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;unistd.h
H5_HAVE_UNISTD_H:INTERNAL=
//Have function vasprintf
H5_HAVE_VASPRINTF:INTERNAL=
//Have function waitpid
H5_HAVE_WAITPID:INTERNAL=
//Have include windows.h;sys/stat.h;sys/types.h;setjmp.h;stddef.h;stdint.h;io.h;winsock2.h
H5_HAVE_WINSOCK2_H:INTERNAL=1
//Other test 
H5_HAVE___INLINE:INTERNAL=1
//Other test 
H5_HAVE___INLINE__:INTERNAL=
//Checking IF correctly converting long double to (unsigned) long
// long values
H5_LDOUBLE_TO_LLONG_ACCURATE:INTERNAL=
//Result of TRY_COMPILE
H5_LDOUBLE_TO_LLONG_ACCURATE_COMPILE:INTERNAL=FALSE
//Checking IF your system converts long double to (unsigned) long
// values with special algorithm
H5_LDOUBLE_TO_LONG_SPECIAL:INTERNAL=
//Result of TRY_COMPILE
H5_LDOUBLE_TO_LONG_SPECIAL_COMPILE:INTERNAL=FALSE
//Checking IF correctly converting (unsigned) long long to long
// double values
H5_LLONG_TO_LDOUBLE_CORRECT:INTERNAL=
//Result of TRY_COMPILE
H5_LLONG_TO_LDOUBLE_CORRECT_COMPILE:INTERNAL=FALSE
//Checking IF your system can convert (unsigned) long to long double
// values with special algorithm
H5_LONG_TO_LDOUBLE_SPECIAL:INTERNAL=
//Result of TRY_COMPILE
H5_LONG_TO_LDOUBLE_SPECIAL_COMPILE:INTERNAL=FALSE
//Checking IF alignment restrictions are strictly enforced
H5_NO_ALIGNMENT_RESTRICTIONS:INTERNAL=
//Result of TRY_COMPILE
H5_NO_ALIGNMENT_RESTRICTIONS_COMPILE:INTERNAL=FALSE
//Result of TRY_COMPILE
H5_PRINTF_LL_TEST_COMPILE:INTERNAL=TRUE
//Result of TRY_RUN
H5_PRINTF_LL_TEST_RUN:INTERNAL=0
//Width for printf for type `long long' or `__int64', us. `ll
H5_PRINTF_LL_WIDTH:INTERNAL="I64"
//CHECK_TYPE_SIZE: sizeof(bool)
H5_SIZEOF_BOOL:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(char)
H5_SIZEOF_CHAR:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(double)
H5_SIZEOF_DOUBLE:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(float)
H5_SIZEOF_FLOAT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int)
H5_SIZEOF_INT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int16_t)
H5_SIZEOF_INT16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(int32_t)
H5_SIZEOF_INT32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int64_t)
H5_SIZEOF_INT64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(int8_t)
H5_SIZEOF_INT8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(int_fast16_t)
H5_SIZEOF_INT_FAST16_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int_fast32_t)
H5_SIZEOF_INT_FAST32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int_fast64_t)
H5_SIZEOF_INT_FAST64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(int_fast8_t)
H5_SIZEOF_INT_FAST8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(int_least16_t)
H5_SIZEOF_INT_LEAST16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(int_least32_t)
H5_SIZEOF_INT_LEAST32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int_least64_t)
H5_SIZEOF_INT_LEAST64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(int_least8_t)
H5_SIZEOF_INT_LEAST8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(long)
H5_SIZEOF_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(long double)
H5_SIZEOF_LONG_DOUBLE:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(long long)
H5_SIZEOF_LONG_LONG:INTERNAL=8
//SizeOf for off64_t
H5_SIZEOF_OFF64_T:INTERNAL=0
//CHECK_TYPE_SIZE: sizeof(off_t)
H5_SIZEOF_OFF_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(short)
H5_SIZEOF_SHORT:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(size_t)
H5_SIZEOF_SIZE_T:INTERNAL=8
//SizeOf for ssize_t
H5_SIZEOF_SSIZE_T:INTERNAL=0
//CHECK_TYPE_SIZE: sizeof(uint16_t)
H5_SIZEOF_UINT16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(uint32_t)
H5_SIZEOF_UINT32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(uint64_t)
H5_SIZEOF_UINT64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(uint8_t)
H5_SIZEOF_UINT8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(uint_fast16_t)
H5_SIZEOF_UINT_FAST16_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(uint_fast32_t)
H5_SIZEOF_UINT_FAST32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(uint_fast64_t)
H5_SIZEOF_UINT_FAST64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(uint_fast8_t)
H5_SIZEOF_UINT_FAST8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(uint_least16_t)
H5_SIZEOF_UINT_LEAST16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(uint_least32_t)
H5_SIZEOF_UINT_LEAST32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(uint_least64_t)
H5_SIZEOF_UINT_LEAST64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(uint_least8_t)
H5_SIZEOF_UINT_LEAST8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(unsigned)
H5_SIZEOF_UNSIGNED:INTERNAL=4
//CHECK_TYPE_SIZE: _Quad unknown
H5_SIZEOF__QUAD:INTERNAL=
//CHECK_TYPE_SIZE: __float128 unknown
H5_SIZEOF___FLOAT128:INTERNAL=
//CHECK_TYPE_SIZE: sizeof(__int64)
H5_SIZEOF___INT64:INTERNAL=8
//Other test 
H5_STDC_HEADERS:INTERNAL=1
//Have symbol alloca
HAVE_ALLOCA:INTERNAL=
//Have include alloca.h
HAVE_ALLOCA_H:INTERNAL=
//Have includes sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ansidecl.h
HAVE_ANSIDECL_H:INTERNAL=
//Have symbol arc4random
HAVE_ARC4RANDOM:INTERNAL=
//Have symbol arc4random_buf
HAVE_ARC4RANDOM_BUF:INTERNAL=
//Have include assert.h
HAVE_ASSERT_H:INTERNAL=1
//Have symbol bcopy
HAVE_BCOPY:INTERNAL=
//Have include byteswap.h
HAVE_BYTESWAP_H:INTERNAL=
//Result of TRY_COMPILE
HAVE_CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=TRUE
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h
HAVE_CTYPE_H:INTERNAL=1
//Have symbol isfinite
HAVE_DECL_ISFINITE:INTERNAL=1
//Have symbol isinf
HAVE_DECL_ISINF:INTERNAL=1
//Have symbol isnan
HAVE_DECL_ISNAN:INTERNAL=1
//Have include dlfcn.h
HAVE_DLFCN_H:INTERNAL=
//Have library 
HAVE_DLOPEN:INTERNAL=
//Have includes sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;dl.h
HAVE_DL_H:INTERNAL=
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h
HAVE_ERRNO_H:INTERNAL=1
//Have include fcntl.h
HAVE_FCNTL_H:INTERNAL=1
//Have include fenv.h
HAVE_FENV_H:INTERNAL=1
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h
HAVE_FLOAT_H:INTERNAL=1
//Have symbol fsync
HAVE_FSYNC:INTERNAL=
//Have symbol getpagesize
HAVE_GETPAGESIZE:INTERNAL=
//Have symbol getrandom
HAVE_GETRANDOM:INTERNAL=
//Have symbol getrlimit
HAVE_GETRLIMIT:INTERNAL=
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_BOOL:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_CHAR:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_DOUBLE:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_FLOAT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_FAST16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_FAST32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_FAST64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_FAST8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_LEAST16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_LEAST32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_LEAST64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_INT_LEAST8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_LONG_DOUBLE:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_OFF64_T:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_OFF_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_SHORT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_SIZE_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_SSIZE_T:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_FAST16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_FAST32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_FAST64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_FAST8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_LEAST16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_LEAST32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_LEAST64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UINT_LEAST8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF_UNSIGNED:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF__QUAD:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF___FLOAT128:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_H5_SIZEOF___INT64:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_HAVE_LONGLONG:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HAVE_LONG_LONG_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_HAVE_SCHAR:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HAVE_SSIZE_T:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HAVE_UCHAR:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HAVE_UINT:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HAVE_USHORT:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE_HOST_BIG_ENDIAN:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_INLINE:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_INT16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_INT32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_INT64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_INTMAX_T:INTERNAL=TRUE
//Have include inttypes.h
HAVE_INTTYPES_H:INTERNAL=1
//Result of TRY_COMPILE
HAVE_IOEO_COMPILED:INTERNAL=TRUE
//Result of TRY_RUN
HAVE_IOEO_EXITCODE:INTERNAL=0
//Have include io.h
HAVE_IO_H:INTERNAL=1
//Test HAVE_LD_VERSION_SCRIPT
HAVE_LD_VERSION_SCRIPT:INTERNAL=
//Have include limits.h
HAVE_LIMITS_H:INTERNAL=1
//Have function localeconv
HAVE_LOCALECONV:INTERNAL=1
//Have symbol localtime
HAVE_LOCALTIME:INTERNAL=1
//CHECK_TYPE_SIZE: longlong unknown
HAVE_LONGLONG:INTERNAL=
//CHECK_TYPE_SIZE: sizeof(long long int)
HAVE_LONG_LONG_INT:INTERNAL=8
//Have include sys/types.h;fcntl.h;malloc.h
HAVE_MALLOC_H:INTERNAL=1
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h
HAVE_MATH_H:INTERNAL=1
//Have symbol memcpy
HAVE_MEMCPY:INTERNAL=1
//Have symbol memmove
HAVE_MEMMOVE:INTERNAL=1
//Have include memory.h
HAVE_MEMORY_H:INTERNAL=1
//Have symbol memset
HAVE_MEMSET:INTERNAL=1
//Have symbol mktemp
HAVE_MKTEMP:INTERNAL=
//Have symbol mmap
HAVE_MMAP:INTERNAL=
//Result of TRY_COMPILE
HAVE_OFF64_T:INTERNAL=FALSE
//Have includes sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;pthread.h
HAVE_PTHREAD_H:INTERNAL=
//Have symbol PTHREAD_MUTEX_RECURSIVE
HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN:INTERNAL=
//Have symbol random
HAVE_RANDOM:INTERNAL=
//CHECK_TYPE_SIZE: schar unknown
HAVE_SCHAR:INTERNAL=
//Have include search.h
HAVE_SEARCH_H:INTERNAL=1
//Have library dld;
HAVE_SHLLOAD:INTERNAL=
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h
HAVE_SIGNAL_H:INTERNAL=1
//Result of TRY_COMPILE
HAVE_SIZEOF_DOUBLE:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_FLOAT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_OFF_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_PTRDIFF_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_SHORT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_SIGNED_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_SIGNED_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_SIGNED_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_SIZE_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_CHAR:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_CHAR_P:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZEOF_UNSIGNED_SHORT_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_INT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_SHORT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_SIZE_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_UNSIGNED:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_UNSIGNED_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_UNSIGNED_LONG_LONG:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_OF_UNSIGNED_SHORT:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_SIZE_T:INTERNAL=TRUE
//Have symbol snprintf
HAVE_SNPRINTF:INTERNAL=1
//CHECK_TYPE_SIZE: ssize_t unknown
HAVE_SSIZE_T:INTERNAL=
//Have symbol stat
HAVE_STAT:INTERNAL=1
//Have include stdarg.h
HAVE_STDARG_H:INTERNAL=1
//Have include stdbool.h
HAVE_STDBOOL_H:INTERNAL=1
//Have include stddef.h
HAVE_STDDEF_H:INTERNAL=1
//Have include stdint.h
HAVE_STDINT_H:INTERNAL=1
//Have include stdlib.h
HAVE_STDLIB_H:INTERNAL=1
//Have symbol strcasecmp
HAVE_STRCASECMP:INTERNAL=
//Have symbol strdup
HAVE_STRDUP:INTERNAL=1
//Have symbol strftime
HAVE_STRFTIME:INTERNAL=1
//Have include strings.h
HAVE_STRINGS_H:INTERNAL=
//Have include string.h
HAVE_STRING_H:INTERNAL=1
//Have symbol strlcat
HAVE_STRLCAT:INTERNAL=
//Have symbol st_blocksize
HAVE_STRUCT_STAT_ST_BLKSIZE:INTERNAL=
//Test HAVE_SYSCALL_GETRANDOM
HAVE_SYSCALL_GETRANDOM:INTERNAL=
//Have symbol sysconf
HAVE_SYSCONF:INTERNAL=
//Have include sys/endian.h
HAVE_SYS_ENDIAN_H:INTERNAL=
//Have include sys/param.h
HAVE_SYS_PARAM_H:INTERNAL=
//Have include sys/resource.h
HAVE_SYS_RESOURCE_H:INTERNAL=
//Have include sys/stat.h
HAVE_SYS_STAT_H:INTERNAL=1
//Have include sys/types.h
HAVE_SYS_TYPES_H:INTERNAL=1
//Have include sys/types.h;fcntl.h;malloc.h;inttypes.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h
HAVE_TIME_H:INTERNAL=1
//CHECK_TYPE_SIZE: uchar unknown
HAVE_UCHAR:INTERNAL=
//CHECK_TYPE_SIZE: uint unknown
HAVE_UINT:INTERNAL=
//Result of TRY_COMPILE
HAVE_UINT16_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_UINT32_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_UINT64_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_UINT8_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_UINTMAX_T:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_UINTPTR_T:INTERNAL=TRUE
//Have include unistd.h
HAVE_UNISTD_H:INTERNAL=
//Result of TRY_COMPILE
HAVE_UNSIGNED___INT64:INTERNAL=TRUE
//CHECK_TYPE_SIZE: ushort unknown
HAVE_USHORT:INTERNAL=
//Result of TRY_COMPILE
HAVE_VA_COPY_COMPILED:INTERNAL=TRUE
//Have symbol vsnprintf
HAVE_VSNPRINTF:INTERNAL=
//Result of TRY_COMPILE
HAVE_VTK_WORDS_BIGENDIAN:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE_WORDS_BIGENDIAN:INTERNAL=TRUE
//Have symbol _stat
HAVE__STAT:INTERNAL=1
//Result of TRY_COMPILE
HAVE___INLINE:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE___INLINE__:INTERNAL=FALSE
//Result of TRY_COMPILE
HAVE___INT64:INTERNAL=TRUE
//Result of TRY_COMPILE
HAVE___VA_COPY_COMPILED:INTERNAL=FALSE
//Have symbol H5free_memory
HDF5_HAS_H5FREE:INTERNAL=
//Have symbol H5Pset_libver_bounds
HDF5_HAS_LIBVER_BOUNDS:INTERNAL=
//Used to pass variables between directories
HDF5_LIBRARIES_TO_EXPORT:INTERNAL=
//Have symbol HDF5_PARALLEL
HDF5_PARALLEL:INTERNAL=
//Used to pass variables between directories
HDF5_UTILS_TO_EXPORT:INTERNAL=
//ADVANCED property for variable: HGCOMMAND
HGCOMMAND-ADVANCED:INTERNAL=1
//Result of TEST_BIG_ENDIAN
HOST_BIG_ENDIAN:INTERNAL=0
//Have include inttypes.h
INCLUDE_INTTYPES_H:INTERNAL=1
//Have include stdint.h
INCLUDE_STDINT_H:INTERNAL=1
//Have include sys/types.h
INCLUDE_SYS_TYPES_H:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(int16_t)
INT16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(int32_t)
INT32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int64_t)
INT64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(intmax_t)
INTMAX_T:INTERNAL=8
//Result of TRY_COMPILE
KWSYS_CXX_HAS_ATOLL_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_ATOL_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_CSTDIO_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_LONG_LONG_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_RLIMIT64_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_SETENV_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_UNSETENV_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_UTIMENSAT_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS_UTIMES_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_HAS__ATOI64_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_HAS___INT64_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_SAME_LONG_AND___INT64_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_SAME_LONG_LONG_AND___INT64_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_CXX_STAT_HAS_ST_MTIMESPEC_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_CXX_STAT_HAS_ST_MTIM_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_C_HAS_CLOCK_GETTIME_MONOTONIC_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_C_HAS_PTRDIFF_T_COMPILED:INTERNAL=TRUE
//Result of TRY_COMPILE
KWSYS_C_HAS_SSIZE_T_COMPILED:INTERNAL=FALSE
//Checking for Large File Support failed to compile.
KWSYS_LFS_WORKS:INTERNAL=-1
//Result of TRY_COMPILE
KWSYS_LFS_WORKS_COMPILED:INTERNAL=FALSE
//Result of TRY_COMPILE
KWSYS_STL_HAS_WSTRING_COMPILED:INTERNAL=TRUE
//Have includes sys/types.h;ifaddrs.h
KWSYS_SYS_HAS_IFADDRS_H:INTERNAL=
//Have symbol GetProcessMemoryInfo
KWSYS_SYS_HAS_PSAPI:INTERNAL=1
//ADVANCED property for variable: MAKECOMMAND
MAKECOMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: MEMORYCHECK_COMMAND
MEMORYCHECK_COMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: MEMORYCHECK_SUPPRESSIONS_FILE
MEMORYCHECK_SUPPRESSIONS_FILE-ADVANCED:INTERNAL=1
//CHECK_TYPE_SIZE: off64_t unknown
OFF64_T:INTERNAL=
//Have symbol off_t
OFF_T:INTERNAL=
//ADVANCED property for variable: OPENGL_gl_LIBRARY
OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OPENGL_glu_LIBRARY
OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OpenVR_INCLUDE_DIR
OpenVR_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: OpenVR_LIBRARY
OpenVR_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: P4COMMAND
P4COMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PYTHON_EXECUTABLE
PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: RMANTREE
RMANTREE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: SCPCOMMAND
SCPCOMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: SITE
SITE-ADVANCED:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(double)
SIZEOF_DOUBLE:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(float)
SIZEOF_FLOAT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(int)
SIZEOF_INT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(long)
SIZEOF_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(long long)
SIZEOF_LONG_LONG:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(off_t)
SIZEOF_OFF_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(ptrdiff_t)
SIZEOF_PTRDIFF_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(short)
SIZEOF_SHORT:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(signed int)
SIZEOF_SIGNED_INT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(signed long)
SIZEOF_SIGNED_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(signed long long)
SIZEOF_SIGNED_LONG_LONG:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(size_t)
SIZEOF_SIZE_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned char)
SIZEOF_UNSIGNED_CHAR:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(unsigned char *)
SIZEOF_UNSIGNED_CHAR_P:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned int)
SIZEOF_UNSIGNED_INT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(unsigned long)
SIZEOF_UNSIGNED_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(unsigned long long)
SIZEOF_UNSIGNED_LONG_LONG:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned short int)
SIZEOF_UNSIGNED_SHORT_INT:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(int)
SIZE_OF_INT:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(long)
SIZE_OF_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(long long)
SIZE_OF_LONG_LONG:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(short)
SIZE_OF_SHORT:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(size_t)
SIZE_OF_SIZE_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned)
SIZE_OF_UNSIGNED:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(unsigned long)
SIZE_OF_UNSIGNED_LONG:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(unsigned long long)
SIZE_OF_UNSIGNED_LONG_LONG:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned short)
SIZE_OF_UNSIGNED_SHORT:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(size_t)
SIZE_T:INTERNAL=8
//ADVANCED property for variable: SLURM_SBATCH_COMMAND
SLURM_SBATCH_COMMAND-ADVANCED:INTERNAL=1
//ADVANCED property for variable: SLURM_SRUN_COMMAND
SLURM_SRUN_COMMAND-ADVANCED:INTERNAL=1
//Result of TRY_COMPILE
STDC_HEADERS:INTERNAL=TRUE
//ADVANCED property for variable: SVNCOMMAND
SVNCOMMAND-ADVANCED:INTERNAL=1
//Test TIME_WITH_SYS_TIME
TIME_WITH_SYS_TIME:INTERNAL=
//Test TM_IN_SYS_TIME
TM_IN_SYS_TIME:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(uint16_t)
UINT16_T:INTERNAL=2
//CHECK_TYPE_SIZE: sizeof(uint32_t)
UINT32_T:INTERNAL=4
//CHECK_TYPE_SIZE: sizeof(uint64_t)
UINT64_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(uint8_t)
UINT8_T:INTERNAL=1
//CHECK_TYPE_SIZE: sizeof(uintmax_t)
UINTMAX_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(uintptr_t)
UINTPTR_T:INTERNAL=8
//CHECK_TYPE_SIZE: sizeof(unsigned __int64)
UNSIGNED___INT64:INTERNAL=8
VTKFREETYPE_BINARY_DIR:INTERNAL=C:/akit/vtk/build/Utilities/freetype
VTKFREETYPE_SOURCE_DIR:INTERNAL=C:/akit/vtk/src/Utilities/freetype
VTKFTGL_BINARY_DIR:INTERNAL=C:/akit/vtk/build/Utilities/ftgl
VTKFTGL_SOURCE_DIR:INTERNAL=C:/akit/vtk/src/Utilities/ftgl
//ADVANCED property for variable: VTK_ALL_NEW_OBJECT_FACTORY
VTK_ALL_NEW_OBJECT_FACTORY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS
VTK_ALWAYS_OPTIMIZE_ARRAY_ITERATORS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_ANDROID_BUILD
VTK_ANDROID_BUILD-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_BUILD_ALL_MODULES
VTK_BUILD_ALL_MODULES-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_BUILD_BODR_DATA_GENERATOR
VTK_BUILD_BODR_DATA_GENERATOR-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_BUILD_TESTING
VTK_BUILD_TESTING-STRINGS:INTERNAL=ON;OFF;WANT
//ADVANCED property for variable: VTK_DATA_EXCLUDE_FROM_ALL
VTK_DATA_EXCLUDE_FROM_ALL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DATA_STORE
VTK_DATA_STORE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DEBUG_LEAKS
VTK_DEBUG_LEAKS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DEFAULT_EGL_DEVICE_INDEX
VTK_DEFAULT_EGL_DEVICE_INDEX-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN
VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DISPATCH_AOS_ARRAYS
VTK_DISPATCH_AOS_ARRAYS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DISPATCH_SOA_ARRAYS
VTK_DISPATCH_SOA_ARRAYS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_DISPATCH_TYPED_ARRAYS
VTK_DISPATCH_TYPED_ARRAYS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_ENABLE_CDASH_THIRD_PARTY_WARNINGS
VTK_ENABLE_CDASH_THIRD_PARTY_WARNINGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_ENABLE_KITS
VTK_ENABLE_KITS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_FORBID_DOWNLOADS
VTK_FORBID_DOWNLOADS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_GHOSTSCRIPT_EXECUTABLE
VTK_GHOSTSCRIPT_EXECUTABLE-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_GROUP_ENABLE_Imaging
VTK_GROUP_ENABLE_Imaging-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_MPI
VTK_GROUP_ENABLE_MPI-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_Qt
VTK_GROUP_ENABLE_Qt-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_Rendering
VTK_GROUP_ENABLE_Rendering-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_StandAlone
VTK_GROUP_ENABLE_StandAlone-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_Tk
VTK_GROUP_ENABLE_Tk-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_Views
VTK_GROUP_ENABLE_Views-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//STRINGS property for variable: VTK_GROUP_ENABLE_Web
VTK_GROUP_ENABLE_Web-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Have symbol feenableexcept
VTK_HAS_FEENABLEEXCEPT:INTERNAL=
//Have symbol finite
VTK_HAS_FINITE:INTERNAL=
//Have symbol InterlockedAdd
VTK_HAS_INTERLOCKEDADD:INTERNAL=1
//Have symbol isfinite
VTK_HAS_ISFINITE:INTERNAL=1
//Have symbol isinf
VTK_HAS_ISINF:INTERNAL=1
//Have symbol isnan
VTK_HAS_ISNAN:INTERNAL=1
//Test VTK_HAS_STD_ISFINITE
VTK_HAS_STD_ISFINITE:INTERNAL=1
//Test VTK_HAS_STD_ISINF
VTK_HAS_STD_ISINF:INTERNAL=1
//Test VTK_HAS_STD_ISNAN
VTK_HAS_STD_ISNAN:INTERNAL=1
//Support for getsockname with socklen_t
VTK_HAVE_GETSOCKNAME_WITH_SOCKLEN_T:INTERNAL=0
//Result of TRY_COMPILE
VTK_HAVE_GETSOCKNAME_WITH_SOCKLEN_T_COMPILED:INTERNAL=FALSE
//Have library socket
VTK_HAVE_LIBSOCKET:INTERNAL=
//Have symbol SO_REUSEADDR
VTK_HAVE_SO_REUSEADDR:INTERNAL=
//ADVANCED property for variable: VTK_IOS_BUILD
VTK_IOS_BUILD-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_LEGACY_REMOVE
VTK_LEGACY_REMOVE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_LEGACY_SILENT
VTK_LEGACY_SILENT-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MAX_THREADS
VTK_MAX_THREADS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_AcceleratorsVTKm
VTK_MODULE_ENABLE_VTK_AcceleratorsVTKm-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_AcceleratorsVTKm
VTK_MODULE_ENABLE_VTK_AcceleratorsVTKm-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ChartsCore
VTK_MODULE_ENABLE_VTK_ChartsCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ChartsCore
VTK_MODULE_ENABLE_VTK_ChartsCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonColor
VTK_MODULE_ENABLE_VTK_CommonColor-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonColor
VTK_MODULE_ENABLE_VTK_CommonColor-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonComputationalGeometry
VTK_MODULE_ENABLE_VTK_CommonComputationalGeometry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonComputationalGeometry
VTK_MODULE_ENABLE_VTK_CommonComputationalGeometry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonCore
VTK_MODULE_ENABLE_VTK_CommonCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonCore
VTK_MODULE_ENABLE_VTK_CommonCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonDataModel
VTK_MODULE_ENABLE_VTK_CommonDataModel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonDataModel
VTK_MODULE_ENABLE_VTK_CommonDataModel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonExecutionModel
VTK_MODULE_ENABLE_VTK_CommonExecutionModel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonExecutionModel
VTK_MODULE_ENABLE_VTK_CommonExecutionModel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonMath
VTK_MODULE_ENABLE_VTK_CommonMath-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonMath
VTK_MODULE_ENABLE_VTK_CommonMath-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonMisc
VTK_MODULE_ENABLE_VTK_CommonMisc-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonMisc
VTK_MODULE_ENABLE_VTK_CommonMisc-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonSystem
VTK_MODULE_ENABLE_VTK_CommonSystem-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonSystem
VTK_MODULE_ENABLE_VTK_CommonSystem-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_CommonTransforms
VTK_MODULE_ENABLE_VTK_CommonTransforms-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_CommonTransforms
VTK_MODULE_ENABLE_VTK_CommonTransforms-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_DICOMParser
VTK_MODULE_ENABLE_VTK_DICOMParser-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_DICOMParser
VTK_MODULE_ENABLE_VTK_DICOMParser-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_DomainsChemistry
VTK_MODULE_ENABLE_VTK_DomainsChemistry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_DomainsChemistry
VTK_MODULE_ENABLE_VTK_DomainsChemistry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2
VTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2
VTK_MODULE_ENABLE_VTK_DomainsChemistryOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_DomainsMicroscopy
VTK_MODULE_ENABLE_VTK_DomainsMicroscopy-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_DomainsMicroscopy
VTK_MODULE_ENABLE_VTK_DomainsMicroscopy-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_DomainsParallelChemistry
VTK_MODULE_ENABLE_VTK_DomainsParallelChemistry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_DomainsParallelChemistry
VTK_MODULE_ENABLE_VTK_DomainsParallelChemistry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersAMR
VTK_MODULE_ENABLE_VTK_FiltersAMR-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersAMR
VTK_MODULE_ENABLE_VTK_FiltersAMR-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersCore
VTK_MODULE_ENABLE_VTK_FiltersCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersCore
VTK_MODULE_ENABLE_VTK_FiltersCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersExtraction
VTK_MODULE_ENABLE_VTK_FiltersExtraction-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersExtraction
VTK_MODULE_ENABLE_VTK_FiltersExtraction-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersFlowPaths
VTK_MODULE_ENABLE_VTK_FiltersFlowPaths-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersFlowPaths
VTK_MODULE_ENABLE_VTK_FiltersFlowPaths-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeneral
VTK_MODULE_ENABLE_VTK_FiltersGeneral-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeneral
VTK_MODULE_ENABLE_VTK_FiltersGeneral-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeneric
VTK_MODULE_ENABLE_VTK_FiltersGeneric-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeneric
VTK_MODULE_ENABLE_VTK_FiltersGeneric-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeometry
VTK_MODULE_ENABLE_VTK_FiltersGeometry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersGeometry
VTK_MODULE_ENABLE_VTK_FiltersGeometry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersHybrid
VTK_MODULE_ENABLE_VTK_FiltersHybrid-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersHybrid
VTK_MODULE_ENABLE_VTK_FiltersHybrid-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersHyperTree
VTK_MODULE_ENABLE_VTK_FiltersHyperTree-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersHyperTree
VTK_MODULE_ENABLE_VTK_FiltersHyperTree-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersImaging
VTK_MODULE_ENABLE_VTK_FiltersImaging-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersImaging
VTK_MODULE_ENABLE_VTK_FiltersImaging-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersModeling
VTK_MODULE_ENABLE_VTK_FiltersModeling-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersModeling
VTK_MODULE_ENABLE_VTK_FiltersModeling-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersOpenTurns
VTK_MODULE_ENABLE_VTK_FiltersOpenTurns-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersOpenTurns
VTK_MODULE_ENABLE_VTK_FiltersOpenTurns-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallel
VTK_MODULE_ENABLE_VTK_FiltersParallel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallel
VTK_MODULE_ENABLE_VTK_FiltersParallel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelDIY2
VTK_MODULE_ENABLE_VTK_FiltersParallelDIY2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelDIY2
VTK_MODULE_ENABLE_VTK_FiltersParallelDIY2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::FiltersParallelDIY2 module. 
VTK_MODULE_ENABLE_VTK_FiltersParallelDIY2:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelFlowPaths
VTK_MODULE_ENABLE_VTK_FiltersParallelFlowPaths-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelFlowPaths
VTK_MODULE_ENABLE_VTK_FiltersParallelFlowPaths-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelGeometry
VTK_MODULE_ENABLE_VTK_FiltersParallelGeometry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelGeometry
VTK_MODULE_ENABLE_VTK_FiltersParallelGeometry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelImaging
VTK_MODULE_ENABLE_VTK_FiltersParallelImaging-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelImaging
VTK_MODULE_ENABLE_VTK_FiltersParallelImaging-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelMPI
VTK_MODULE_ENABLE_VTK_FiltersParallelMPI-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelMPI
VTK_MODULE_ENABLE_VTK_FiltersParallelMPI-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelStatistics
VTK_MODULE_ENABLE_VTK_FiltersParallelStatistics-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelStatistics
VTK_MODULE_ENABLE_VTK_FiltersParallelStatistics-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelVerdict
VTK_MODULE_ENABLE_VTK_FiltersParallelVerdict-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersParallelVerdict
VTK_MODULE_ENABLE_VTK_FiltersParallelVerdict-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersPoints
VTK_MODULE_ENABLE_VTK_FiltersPoints-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersPoints
VTK_MODULE_ENABLE_VTK_FiltersPoints-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersProgrammable
VTK_MODULE_ENABLE_VTK_FiltersProgrammable-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersProgrammable
VTK_MODULE_ENABLE_VTK_FiltersProgrammable-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersPython
VTK_MODULE_ENABLE_VTK_FiltersPython-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersPython
VTK_MODULE_ENABLE_VTK_FiltersPython-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::FiltersPython module. 
VTK_MODULE_ENABLE_VTK_FiltersPython:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersReebGraph
VTK_MODULE_ENABLE_VTK_FiltersReebGraph-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersReebGraph
VTK_MODULE_ENABLE_VTK_FiltersReebGraph-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersSMP
VTK_MODULE_ENABLE_VTK_FiltersSMP-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersSMP
VTK_MODULE_ENABLE_VTK_FiltersSMP-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersSelection
VTK_MODULE_ENABLE_VTK_FiltersSelection-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersSelection
VTK_MODULE_ENABLE_VTK_FiltersSelection-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersSources
VTK_MODULE_ENABLE_VTK_FiltersSources-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersSources
VTK_MODULE_ENABLE_VTK_FiltersSources-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersStatistics
VTK_MODULE_ENABLE_VTK_FiltersStatistics-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersStatistics
VTK_MODULE_ENABLE_VTK_FiltersStatistics-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersTexture
VTK_MODULE_ENABLE_VTK_FiltersTexture-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersTexture
VTK_MODULE_ENABLE_VTK_FiltersTexture-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersTopology
VTK_MODULE_ENABLE_VTK_FiltersTopology-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersTopology
VTK_MODULE_ENABLE_VTK_FiltersTopology-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_FiltersVerdict
VTK_MODULE_ENABLE_VTK_FiltersVerdict-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_FiltersVerdict
VTK_MODULE_ENABLE_VTK_FiltersVerdict-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GUISupportMFC
VTK_MODULE_ENABLE_VTK_GUISupportMFC-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GUISupportMFC
VTK_MODULE_ENABLE_VTK_GUISupportMFC-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQt
VTK_MODULE_ENABLE_VTK_GUISupportQt-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQt
VTK_MODULE_ENABLE_VTK_GUISupportQt-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQtOpenGL
VTK_MODULE_ENABLE_VTK_GUISupportQtOpenGL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQtOpenGL
VTK_MODULE_ENABLE_VTK_GUISupportQtOpenGL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQtSQL
VTK_MODULE_ENABLE_VTK_GUISupportQtSQL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GUISupportQtSQL
VTK_MODULE_ENABLE_VTK_GUISupportQtSQL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GeovisCore
VTK_MODULE_ENABLE_VTK_GeovisCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GeovisCore
VTK_MODULE_ENABLE_VTK_GeovisCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_GeovisGDAL
VTK_MODULE_ENABLE_VTK_GeovisGDAL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_GeovisGDAL
VTK_MODULE_ENABLE_VTK_GeovisGDAL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOADIOS
VTK_MODULE_ENABLE_VTK_IOADIOS-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOADIOS
VTK_MODULE_ENABLE_VTK_IOADIOS-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOAMR
VTK_MODULE_ENABLE_VTK_IOAMR-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOAMR
VTK_MODULE_ENABLE_VTK_IOAMR-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOAsynchronous
VTK_MODULE_ENABLE_VTK_IOAsynchronous-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOAsynchronous
VTK_MODULE_ENABLE_VTK_IOAsynchronous-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOCityGML
VTK_MODULE_ENABLE_VTK_IOCityGML-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOCityGML
VTK_MODULE_ENABLE_VTK_IOCityGML-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOCore
VTK_MODULE_ENABLE_VTK_IOCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOCore
VTK_MODULE_ENABLE_VTK_IOCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOEnSight
VTK_MODULE_ENABLE_VTK_IOEnSight-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOEnSight
VTK_MODULE_ENABLE_VTK_IOEnSight-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOExodus
VTK_MODULE_ENABLE_VTK_IOExodus-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOExodus
VTK_MODULE_ENABLE_VTK_IOExodus-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOExport
VTK_MODULE_ENABLE_VTK_IOExport-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOExport
VTK_MODULE_ENABLE_VTK_IOExport-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOExportGL2PS
VTK_MODULE_ENABLE_VTK_IOExportGL2PS-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOExportGL2PS
VTK_MODULE_ENABLE_VTK_IOExportGL2PS-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOExportPDF
VTK_MODULE_ENABLE_VTK_IOExportPDF-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOExportPDF
VTK_MODULE_ENABLE_VTK_IOExportPDF-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOFFMPEG
VTK_MODULE_ENABLE_VTK_IOFFMPEG-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOFFMPEG
VTK_MODULE_ENABLE_VTK_IOFFMPEG-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOGDAL
VTK_MODULE_ENABLE_VTK_IOGDAL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOGDAL
VTK_MODULE_ENABLE_VTK_IOGDAL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOGeoJSON
VTK_MODULE_ENABLE_VTK_IOGeoJSON-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOGeoJSON
VTK_MODULE_ENABLE_VTK_IOGeoJSON-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOGeometry
VTK_MODULE_ENABLE_VTK_IOGeometry-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOGeometry
VTK_MODULE_ENABLE_VTK_IOGeometry-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOImage
VTK_MODULE_ENABLE_VTK_IOImage-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOImage
VTK_MODULE_ENABLE_VTK_IOImage-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOImport
VTK_MODULE_ENABLE_VTK_IOImport-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOImport
VTK_MODULE_ENABLE_VTK_IOImport-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOInfovis
VTK_MODULE_ENABLE_VTK_IOInfovis-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOInfovis
VTK_MODULE_ENABLE_VTK_IOInfovis-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOLAS
VTK_MODULE_ENABLE_VTK_IOLAS-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOLAS
VTK_MODULE_ENABLE_VTK_IOLAS-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOLSDyna
VTK_MODULE_ENABLE_VTK_IOLSDyna-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOLSDyna
VTK_MODULE_ENABLE_VTK_IOLSDyna-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOLegacy
VTK_MODULE_ENABLE_VTK_IOLegacy-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOLegacy
VTK_MODULE_ENABLE_VTK_IOLegacy-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMINC
VTK_MODULE_ENABLE_VTK_IOMINC-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMINC
VTK_MODULE_ENABLE_VTK_IOMINC-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMPIImage
VTK_MODULE_ENABLE_VTK_IOMPIImage-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMPIImage
VTK_MODULE_ENABLE_VTK_IOMPIImage-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMPIParallel
VTK_MODULE_ENABLE_VTK_IOMPIParallel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMPIParallel
VTK_MODULE_ENABLE_VTK_IOMPIParallel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::IOMPIParallel module. 
VTK_MODULE_ENABLE_VTK_IOMPIParallel:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMotionFX
VTK_MODULE_ENABLE_VTK_IOMotionFX-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMotionFX
VTK_MODULE_ENABLE_VTK_IOMotionFX-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMovie
VTK_MODULE_ENABLE_VTK_IOMovie-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMovie
VTK_MODULE_ENABLE_VTK_IOMovie-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOMySQL
VTK_MODULE_ENABLE_VTK_IOMySQL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOMySQL
VTK_MODULE_ENABLE_VTK_IOMySQL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IONetCDF
VTK_MODULE_ENABLE_VTK_IONetCDF-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IONetCDF
VTK_MODULE_ENABLE_VTK_IONetCDF-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOODBC
VTK_MODULE_ENABLE_VTK_IOODBC-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOODBC
VTK_MODULE_ENABLE_VTK_IOODBC-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOOggTheora
VTK_MODULE_ENABLE_VTK_IOOggTheora-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOOggTheora
VTK_MODULE_ENABLE_VTK_IOOggTheora-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOPDAL
VTK_MODULE_ENABLE_VTK_IOPDAL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOPDAL
VTK_MODULE_ENABLE_VTK_IOPDAL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOPLY
VTK_MODULE_ENABLE_VTK_IOPLY-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOPLY
VTK_MODULE_ENABLE_VTK_IOPLY-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallel
VTK_MODULE_ENABLE_VTK_IOParallel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallel
VTK_MODULE_ENABLE_VTK_IOParallel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallelExodus
VTK_MODULE_ENABLE_VTK_IOParallelExodus-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallelExodus
VTK_MODULE_ENABLE_VTK_IOParallelExodus-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallelLSDyna
VTK_MODULE_ENABLE_VTK_IOParallelLSDyna-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallelLSDyna
VTK_MODULE_ENABLE_VTK_IOParallelLSDyna-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallelNetCDF
VTK_MODULE_ENABLE_VTK_IOParallelNetCDF-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallelNetCDF
VTK_MODULE_ENABLE_VTK_IOParallelNetCDF-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallelXML
VTK_MODULE_ENABLE_VTK_IOParallelXML-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallelXML
VTK_MODULE_ENABLE_VTK_IOParallelXML-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOParallelXdmf3
VTK_MODULE_ENABLE_VTK_IOParallelXdmf3-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOParallelXdmf3
VTK_MODULE_ENABLE_VTK_IOParallelXdmf3-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOPostgreSQL
VTK_MODULE_ENABLE_VTK_IOPostgreSQL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOPostgreSQL
VTK_MODULE_ENABLE_VTK_IOPostgreSQL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOSQL
VTK_MODULE_ENABLE_VTK_IOSQL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOSQL
VTK_MODULE_ENABLE_VTK_IOSQL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOSegY
VTK_MODULE_ENABLE_VTK_IOSegY-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOSegY
VTK_MODULE_ENABLE_VTK_IOSegY-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOTRUCHAS
VTK_MODULE_ENABLE_VTK_IOTRUCHAS-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOTRUCHAS
VTK_MODULE_ENABLE_VTK_IOTRUCHAS-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOTecplotTable
VTK_MODULE_ENABLE_VTK_IOTecplotTable-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOTecplotTable
VTK_MODULE_ENABLE_VTK_IOTecplotTable-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOVPIC
VTK_MODULE_ENABLE_VTK_IOVPIC-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOVPIC
VTK_MODULE_ENABLE_VTK_IOVPIC-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOVeraOut
VTK_MODULE_ENABLE_VTK_IOVeraOut-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOVeraOut
VTK_MODULE_ENABLE_VTK_IOVeraOut-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOVideo
VTK_MODULE_ENABLE_VTK_IOVideo-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOVideo
VTK_MODULE_ENABLE_VTK_IOVideo-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOXML
VTK_MODULE_ENABLE_VTK_IOXML-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOXML
VTK_MODULE_ENABLE_VTK_IOXML-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOXMLParser
VTK_MODULE_ENABLE_VTK_IOXMLParser-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOXMLParser
VTK_MODULE_ENABLE_VTK_IOXMLParser-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOXdmf2
VTK_MODULE_ENABLE_VTK_IOXdmf2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOXdmf2
VTK_MODULE_ENABLE_VTK_IOXdmf2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_IOXdmf3
VTK_MODULE_ENABLE_VTK_IOXdmf3-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_IOXdmf3
VTK_MODULE_ENABLE_VTK_IOXdmf3-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingColor
VTK_MODULE_ENABLE_VTK_ImagingColor-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingColor
VTK_MODULE_ENABLE_VTK_ImagingColor-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingCore
VTK_MODULE_ENABLE_VTK_ImagingCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingCore
VTK_MODULE_ENABLE_VTK_ImagingCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingFourier
VTK_MODULE_ENABLE_VTK_ImagingFourier-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingFourier
VTK_MODULE_ENABLE_VTK_ImagingFourier-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingGeneral
VTK_MODULE_ENABLE_VTK_ImagingGeneral-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingGeneral
VTK_MODULE_ENABLE_VTK_ImagingGeneral-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingHybrid
VTK_MODULE_ENABLE_VTK_ImagingHybrid-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingHybrid
VTK_MODULE_ENABLE_VTK_ImagingHybrid-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingMath
VTK_MODULE_ENABLE_VTK_ImagingMath-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingMath
VTK_MODULE_ENABLE_VTK_ImagingMath-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingMorphological
VTK_MODULE_ENABLE_VTK_ImagingMorphological-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingMorphological
VTK_MODULE_ENABLE_VTK_ImagingMorphological-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingOpenGL2
VTK_MODULE_ENABLE_VTK_ImagingOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingOpenGL2
VTK_MODULE_ENABLE_VTK_ImagingOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingSources
VTK_MODULE_ENABLE_VTK_ImagingSources-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingSources
VTK_MODULE_ENABLE_VTK_ImagingSources-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingStatistics
VTK_MODULE_ENABLE_VTK_ImagingStatistics-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingStatistics
VTK_MODULE_ENABLE_VTK_ImagingStatistics-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ImagingStencil
VTK_MODULE_ENABLE_VTK_ImagingStencil-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ImagingStencil
VTK_MODULE_ENABLE_VTK_ImagingStencil-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InfovisBoost
VTK_MODULE_ENABLE_VTK_InfovisBoost-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InfovisBoost
VTK_MODULE_ENABLE_VTK_InfovisBoost-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms
VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms
VTK_MODULE_ENABLE_VTK_InfovisBoostGraphAlgorithms-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InfovisCore
VTK_MODULE_ENABLE_VTK_InfovisCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InfovisCore
VTK_MODULE_ENABLE_VTK_InfovisCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InfovisLayout
VTK_MODULE_ENABLE_VTK_InfovisLayout-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InfovisLayout
VTK_MODULE_ENABLE_VTK_InfovisLayout-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InteractionImage
VTK_MODULE_ENABLE_VTK_InteractionImage-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InteractionImage
VTK_MODULE_ENABLE_VTK_InteractionImage-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InteractionStyle
VTK_MODULE_ENABLE_VTK_InteractionStyle-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InteractionStyle
VTK_MODULE_ENABLE_VTK_InteractionStyle-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_InteractionWidgets
VTK_MODULE_ENABLE_VTK_InteractionWidgets-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_InteractionWidgets
VTK_MODULE_ENABLE_VTK_InteractionWidgets-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ParallelCore
VTK_MODULE_ENABLE_VTK_ParallelCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ParallelCore
VTK_MODULE_ENABLE_VTK_ParallelCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ParallelMPI
VTK_MODULE_ENABLE_VTK_ParallelMPI-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ParallelMPI
VTK_MODULE_ENABLE_VTK_ParallelMPI-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ParallelMPI4Py
VTK_MODULE_ENABLE_VTK_ParallelMPI4Py-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ParallelMPI4Py
VTK_MODULE_ENABLE_VTK_ParallelMPI4Py-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::ParallelMPI4Py module. 
VTK_MODULE_ENABLE_VTK_ParallelMPI4Py:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_PythonContext2D
VTK_MODULE_ENABLE_VTK_PythonContext2D-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_PythonContext2D
VTK_MODULE_ENABLE_VTK_PythonContext2D-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::PythonContext2D module. 
VTK_MODULE_ENABLE_VTK_PythonContext2D:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_PythonInterpreter
VTK_MODULE_ENABLE_VTK_PythonInterpreter-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_PythonInterpreter
VTK_MODULE_ENABLE_VTK_PythonInterpreter-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingAnnotation
VTK_MODULE_ENABLE_VTK_RenderingAnnotation-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingAnnotation
VTK_MODULE_ENABLE_VTK_RenderingAnnotation-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingContext2D
VTK_MODULE_ENABLE_VTK_RenderingContext2D-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingContext2D
VTK_MODULE_ENABLE_VTK_RenderingContext2D-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingCore
VTK_MODULE_ENABLE_VTK_RenderingCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingCore
VTK_MODULE_ENABLE_VTK_RenderingCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingExternal
VTK_MODULE_ENABLE_VTK_RenderingExternal-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingExternal
VTK_MODULE_ENABLE_VTK_RenderingExternal-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingFreeType
VTK_MODULE_ENABLE_VTK_RenderingFreeType-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingFreeType
VTK_MODULE_ENABLE_VTK_RenderingFreeType-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig
VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig
VTK_MODULE_ENABLE_VTK_RenderingFreeTypeFontConfig-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingImage
VTK_MODULE_ENABLE_VTK_RenderingImage-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingImage
VTK_MODULE_ENABLE_VTK_RenderingImage-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingLICOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingLICOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingLICOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingLICOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingLOD
VTK_MODULE_ENABLE_VTK_RenderingLOD-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingLOD
VTK_MODULE_ENABLE_VTK_RenderingLOD-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingLabel
VTK_MODULE_ENABLE_VTK_RenderingLabel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingLabel
VTK_MODULE_ENABLE_VTK_RenderingLabel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingMatplotlib
VTK_MODULE_ENABLE_VTK_RenderingMatplotlib-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingMatplotlib
VTK_MODULE_ENABLE_VTK_RenderingMatplotlib-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingOSPRay
VTK_MODULE_ENABLE_VTK_RenderingOSPRay-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingOSPRay
VTK_MODULE_ENABLE_VTK_RenderingOSPRay-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingOpenVR
VTK_MODULE_ENABLE_VTK_RenderingOpenVR-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingOpenVR
VTK_MODULE_ENABLE_VTK_RenderingOpenVR-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingOptiX
VTK_MODULE_ENABLE_VTK_RenderingOptiX-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingOptiX
VTK_MODULE_ENABLE_VTK_RenderingOptiX-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingParallel
VTK_MODULE_ENABLE_VTK_RenderingParallel-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingParallel
VTK_MODULE_ENABLE_VTK_RenderingParallel-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingParallelLIC
VTK_MODULE_ENABLE_VTK_RenderingParallelLIC-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingParallelLIC
VTK_MODULE_ENABLE_VTK_RenderingParallelLIC-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingQt
VTK_MODULE_ENABLE_VTK_RenderingQt-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingQt
VTK_MODULE_ENABLE_VTK_RenderingQt-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingSceneGraph
VTK_MODULE_ENABLE_VTK_RenderingSceneGraph-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingSceneGraph
VTK_MODULE_ENABLE_VTK_RenderingSceneGraph-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingTk
VTK_MODULE_ENABLE_VTK_RenderingTk-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingTk
VTK_MODULE_ENABLE_VTK_RenderingTk-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::RenderingTk module. 
VTK_MODULE_ENABLE_VTK_RenderingTk:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolume
VTK_MODULE_ENABLE_VTK_RenderingVolume-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolume
VTK_MODULE_ENABLE_VTK_RenderingVolume-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolumeAMR
VTK_MODULE_ENABLE_VTK_RenderingVolumeAMR-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolumeAMR
VTK_MODULE_ENABLE_VTK_RenderingVolumeAMR-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2
VTK_MODULE_ENABLE_VTK_RenderingVolumeOpenGL2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_TestingCore
VTK_MODULE_ENABLE_VTK_TestingCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_TestingCore
VTK_MODULE_ENABLE_VTK_TestingCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_TestingGenericBridge
VTK_MODULE_ENABLE_VTK_TestingGenericBridge-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_TestingGenericBridge
VTK_MODULE_ENABLE_VTK_TestingGenericBridge-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_TestingIOSQL
VTK_MODULE_ENABLE_VTK_TestingIOSQL-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_TestingIOSQL
VTK_MODULE_ENABLE_VTK_TestingIOSQL-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_TestingRendering
VTK_MODULE_ENABLE_VTK_TestingRendering-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_TestingRendering
VTK_MODULE_ENABLE_VTK_TestingRendering-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks
VTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks
VTK_MODULE_ENABLE_VTK_UtilitiesBenchmarks-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ViewsContext2D
VTK_MODULE_ENABLE_VTK_ViewsContext2D-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ViewsContext2D
VTK_MODULE_ENABLE_VTK_ViewsContext2D-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ViewsCore
VTK_MODULE_ENABLE_VTK_ViewsCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ViewsCore
VTK_MODULE_ENABLE_VTK_ViewsCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ViewsGeovis
VTK_MODULE_ENABLE_VTK_ViewsGeovis-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ViewsGeovis
VTK_MODULE_ENABLE_VTK_ViewsGeovis-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::ViewsGeovis module. 
VTK_MODULE_ENABLE_VTK_ViewsGeovis:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ViewsInfovis
VTK_MODULE_ENABLE_VTK_ViewsInfovis-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ViewsInfovis
VTK_MODULE_ENABLE_VTK_ViewsInfovis-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ViewsQt
VTK_MODULE_ENABLE_VTK_ViewsQt-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ViewsQt
VTK_MODULE_ENABLE_VTK_ViewsQt-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_WebCore
VTK_MODULE_ENABLE_VTK_WebCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_WebCore
VTK_MODULE_ENABLE_VTK_WebCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_WebGLExporter
VTK_MODULE_ENABLE_VTK_WebGLExporter-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_WebGLExporter
VTK_MODULE_ENABLE_VTK_WebGLExporter-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_WebPython
VTK_MODULE_ENABLE_VTK_WebPython-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_WebPython
VTK_MODULE_ENABLE_VTK_WebPython-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//Enable the VTK::WebPython module. 
VTK_MODULE_ENABLE_VTK_WebPython:INTERNAL=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_WrappingPythonCore
VTK_MODULE_ENABLE_VTK_WrappingPythonCore-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_WrappingPythonCore
VTK_MODULE_ENABLE_VTK_WrappingPythonCore-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_WrappingTools
VTK_MODULE_ENABLE_VTK_WrappingTools-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_WrappingTools
VTK_MODULE_ENABLE_VTK_WrappingTools-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_diy2
VTK_MODULE_ENABLE_VTK_diy2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_diy2
VTK_MODULE_ENABLE_VTK_diy2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_doubleconversion
VTK_MODULE_ENABLE_VTK_doubleconversion-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_doubleconversion
VTK_MODULE_ENABLE_VTK_doubleconversion-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_eigen
VTK_MODULE_ENABLE_VTK_eigen-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_eigen
VTK_MODULE_ENABLE_VTK_eigen-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_exodusII
VTK_MODULE_ENABLE_VTK_exodusII-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_exodusII
VTK_MODULE_ENABLE_VTK_exodusII-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_expat
VTK_MODULE_ENABLE_VTK_expat-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_expat
VTK_MODULE_ENABLE_VTK_expat-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_freetype
VTK_MODULE_ENABLE_VTK_freetype-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_freetype
VTK_MODULE_ENABLE_VTK_freetype-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_gl2ps
VTK_MODULE_ENABLE_VTK_gl2ps-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_gl2ps
VTK_MODULE_ENABLE_VTK_gl2ps-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_glew
VTK_MODULE_ENABLE_VTK_glew-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_glew
VTK_MODULE_ENABLE_VTK_glew-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_hdf5
VTK_MODULE_ENABLE_VTK_hdf5-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_hdf5
VTK_MODULE_ENABLE_VTK_hdf5-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_jpeg
VTK_MODULE_ENABLE_VTK_jpeg-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_jpeg
VTK_MODULE_ENABLE_VTK_jpeg-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_jsoncpp
VTK_MODULE_ENABLE_VTK_jsoncpp-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_jsoncpp
VTK_MODULE_ENABLE_VTK_jsoncpp-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_kissfft
VTK_MODULE_ENABLE_VTK_kissfft-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_kissfft
VTK_MODULE_ENABLE_VTK_kissfft-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_kwiml
VTK_MODULE_ENABLE_VTK_kwiml-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_kwiml
VTK_MODULE_ENABLE_VTK_kwiml-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_libharu
VTK_MODULE_ENABLE_VTK_libharu-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_libharu
VTK_MODULE_ENABLE_VTK_libharu-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_libproj
VTK_MODULE_ENABLE_VTK_libproj-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_libproj
VTK_MODULE_ENABLE_VTK_libproj-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_libxml2
VTK_MODULE_ENABLE_VTK_libxml2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_libxml2
VTK_MODULE_ENABLE_VTK_libxml2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_lz4
VTK_MODULE_ENABLE_VTK_lz4-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_lz4
VTK_MODULE_ENABLE_VTK_lz4-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_lzma
VTK_MODULE_ENABLE_VTK_lzma-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_lzma
VTK_MODULE_ENABLE_VTK_lzma-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_metaio
VTK_MODULE_ENABLE_VTK_metaio-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_metaio
VTK_MODULE_ENABLE_VTK_metaio-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_mpi4py
VTK_MODULE_ENABLE_VTK_mpi4py-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_mpi4py
VTK_MODULE_ENABLE_VTK_mpi4py-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_netcdf
VTK_MODULE_ENABLE_VTK_netcdf-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_netcdf
VTK_MODULE_ENABLE_VTK_netcdf-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_octree
VTK_MODULE_ENABLE_VTK_octree-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_octree
VTK_MODULE_ENABLE_VTK_octree-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_ogg
VTK_MODULE_ENABLE_VTK_ogg-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_ogg
VTK_MODULE_ENABLE_VTK_ogg-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_opengl
VTK_MODULE_ENABLE_VTK_opengl-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_opengl
VTK_MODULE_ENABLE_VTK_opengl-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_pegtl
VTK_MODULE_ENABLE_VTK_pegtl-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_pegtl
VTK_MODULE_ENABLE_VTK_pegtl-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_png
VTK_MODULE_ENABLE_VTK_png-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_png
VTK_MODULE_ENABLE_VTK_png-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_pugixml
VTK_MODULE_ENABLE_VTK_pugixml-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_pugixml
VTK_MODULE_ENABLE_VTK_pugixml-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_sqlite
VTK_MODULE_ENABLE_VTK_sqlite-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_sqlite
VTK_MODULE_ENABLE_VTK_sqlite-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_theora
VTK_MODULE_ENABLE_VTK_theora-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_theora
VTK_MODULE_ENABLE_VTK_theora-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_tiff
VTK_MODULE_ENABLE_VTK_tiff-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_tiff
VTK_MODULE_ENABLE_VTK_tiff-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_utf8
VTK_MODULE_ENABLE_VTK_utf8-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_utf8
VTK_MODULE_ENABLE_VTK_utf8-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_verdict
VTK_MODULE_ENABLE_VTK_verdict-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_verdict
VTK_MODULE_ENABLE_VTK_verdict-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_vpic
VTK_MODULE_ENABLE_VTK_vpic-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_vpic
VTK_MODULE_ENABLE_VTK_vpic-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_vtkm
VTK_MODULE_ENABLE_VTK_vtkm-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_vtkm
VTK_MODULE_ENABLE_VTK_vtkm-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_vtksys
VTK_MODULE_ENABLE_VTK_vtksys-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_vtksys
VTK_MODULE_ENABLE_VTK_vtksys-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_xdmf2
VTK_MODULE_ENABLE_VTK_xdmf2-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_xdmf2
VTK_MODULE_ENABLE_VTK_xdmf2-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_xdmf3
VTK_MODULE_ENABLE_VTK_xdmf3-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_xdmf3
VTK_MODULE_ENABLE_VTK_xdmf3-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_zfp
VTK_MODULE_ENABLE_VTK_zfp-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_zfp
VTK_MODULE_ENABLE_VTK_zfp-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_VTK_zlib
VTK_MODULE_ENABLE_VTK_zlib-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_VTK_zlib
VTK_MODULE_ENABLE_VTK_zlib-STRINGS:INTERNAL=YES;WANT;DONT_WANT;NO;DEFAULT
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_doubleconversion
VTK_MODULE_USE_EXTERNAL_VTK_doubleconversion-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_eigen
VTK_MODULE_USE_EXTERNAL_VTK_eigen-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_expat
VTK_MODULE_USE_EXTERNAL_VTK_expat-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_freetype
VTK_MODULE_USE_EXTERNAL_VTK_freetype-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_gl2ps
VTK_MODULE_USE_EXTERNAL_VTK_gl2ps-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_glew
VTK_MODULE_USE_EXTERNAL_VTK_glew-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_hdf5
VTK_MODULE_USE_EXTERNAL_VTK_hdf5-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_jpeg
VTK_MODULE_USE_EXTERNAL_VTK_jpeg-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_jsoncpp
VTK_MODULE_USE_EXTERNAL_VTK_jsoncpp-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_libharu
VTK_MODULE_USE_EXTERNAL_VTK_libharu-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_libproj
VTK_MODULE_USE_EXTERNAL_VTK_libproj-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_libxml2
VTK_MODULE_USE_EXTERNAL_VTK_libxml2-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_lz4
VTK_MODULE_USE_EXTERNAL_VTK_lz4-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_lzma
VTK_MODULE_USE_EXTERNAL_VTK_lzma-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_netcdf
VTK_MODULE_USE_EXTERNAL_VTK_netcdf-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_ogg
VTK_MODULE_USE_EXTERNAL_VTK_ogg-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_png
VTK_MODULE_USE_EXTERNAL_VTK_png-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_sqlite
VTK_MODULE_USE_EXTERNAL_VTK_sqlite-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_theora
VTK_MODULE_USE_EXTERNAL_VTK_theora-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_tiff
VTK_MODULE_USE_EXTERNAL_VTK_tiff-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_MODULE_USE_EXTERNAL_VTK_zlib
VTK_MODULE_USE_EXTERNAL_VTK_zlib-ADVANCED:INTERNAL=1
//Maximum number of processors available to run parallel applications.
VTK_MPI_MAX_NUMPROCS:INTERNAL=1
//ADVANCED property for variable: VTK_OPENGL_ENABLE_STREAM_ANNOTATIONS
VTK_OPENGL_ENABLE_STREAM_ANNOTATIONS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_OPENGL_HAS_EGL
VTK_OPENGL_HAS_EGL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_OPENGL_HAS_OSMESA
VTK_OPENGL_HAS_OSMESA-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_OPENGL_USE_GLES
VTK_OPENGL_USE_GLES-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_PYTHON_VERSION
VTK_PYTHON_VERSION-STRINGS:INTERNAL=2;3
//ADVANCED property for variable: VTK_RELOCATABLE_INSTALL
VTK_RELOCATABLE_INSTALL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS
VTK_REPORT_OPENGL_ERRORS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS
VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_SMP_IMPLEMENTATION_TYPE
VTK_SMP_IMPLEMENTATION_TYPE-STRINGS:INTERNAL=Sequential;OpenMP;TBB
//ADVANCED property for variable: VTK_USE_64BIT_IDS
VTK_USE_64BIT_IDS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_USE_EXTERNAL
VTK_USE_EXTERNAL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_USE_OPENGL_DELAYED_LOAD
VTK_USE_OPENGL_DELAYED_LOAD-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_USE_VIDEO_FOR_WINDOWS
VTK_USE_VIDEO_FOR_WINDOWS-ADVANCED:INTERNAL=1
//Result of TRY_COMPILE
VTK_USE_VIDEO_FOR_WINDOWS_DEFAULT:INTERNAL=TRUE
//ADVANCED property for variable: VTK_USE_X
VTK_USE_X-ADVANCED:INTERNAL=1
//Enable using Video for Windows (vfw32) for video capture.
VTK_VFW_SUPPORTS_CAPTURE:INTERNAL=1
//ADVANCED property for variable: VTK_WARN_ON_DISPATCH_FAILURE
VTK_WARN_ON_DISPATCH_FAILURE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: VTK_WKHTMLTOIMAGE_EXECUTABLE
VTK_WKHTMLTOIMAGE_EXECUTABLE-ADVANCED:INTERNAL=1
//Result of TEST_BIG_ENDIAN
VTK_WORDS_BIGENDIAN:INTERNAL=0
//Result of TEST_BIG_ENDIAN
WORDS_BIGENDIAN:INTERNAL=0
//Have include unistd.h
Z_HAVE_UNISTD_H:INTERNAL=
//CMAKE_INSTALL_PREFIX during last run
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX:INTERNAL=C:/akit/vtk/install
//CHECK_TYPE_SIZE: sizeof(__int64)
__INT64:INTERNAL=8
//Test have_flag_logical-op-parentheses
have_flag_logical-op-parentheses:INTERNAL=
//Test have_flag_parentheses
have_flag_parentheses:INTERNAL=
//Test have_flag_shift-op-parentheses
have_flag_shift-op-parentheses:INTERNAL=
//Test have_flag_tautological-compare
have_flag_tautological-compare:INTERNAL=
//Test standard_math_library_linked_to_automatically
standard_math_library_linked_to_automatically:INTERNAL=1


From sean at rogue-research.com  Wed Jan 23 11:48:00 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 11:48:00 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190110220712.GA21739@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
Message-ID: <20190123164800.1354162260@mail.rogue-research.com>

On Thu, 10 Jan 2019 17:07:12 -0500, Ben Boeckel via vtk-developers said:

>All third party warnings have been suppressed for now (though some may
>slip through yet). I'll deal with those in the future.

Any news on this?  My bot submissions have lots and lots of 3rd party warnings...  (They didn't used to.)

Cheers,

Sean



From ben.boeckel at kitware.com  Wed Jan 23 11:54:26 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 11:54:26 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
 <20190123140503.GB30183@megas.kitware.com>
 <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>
Message-ID: <20190123165426.GA3725@megas.kitware.com>

On Wed, Jan 23, 2019 at 10:12:18 -0500, Aron Helser wrote:
> Hopefully the OpenVR and FFMPEG stuff aren't relevant, and can be omitted.
> I'll test that.
> I'll attach my cmakecache, too

It doesn't fail on Linux here. Some debugging on Windows will be
necessary. But, I don't have OpenVR enabled (FFMPEG is).

--Ben

From ben.boeckel at kitware.com  Wed Jan 23 13:42:25 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 13:42:25 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123164800.1354162260@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
Message-ID: <20190123184225.GA11145@megas.kitware.com>

On Wed, Jan 23, 2019 at 11:48:00 -0500, Sean McBride wrote:
> On Thu, 10 Jan 2019 17:07:12 -0500, Ben Boeckel via vtk-developers said:
> >All third party warnings have been suppressed for now (though some may
> >slip through yet). I'll deal with those in the future.
> 
> Any news on this?  My bot submissions have lots and lots of 3rd party
> warnings...

No, I haven't gotten to this yet. The vast majority are from one warning
(redefinition of PRI64 or something), so fixing that one should help a
lot. That should be fixed upstream and brought back into VTK though.
There are others which should really be fixed upstream too.

> (They didn't used to.)

Well, we used to ignore all kinds of warnings on CDash (they still
appeared in local builds though).

If you or anyone else would like to tackle it, testing fixes on buildbot
with direct changes before finalizing the patches to go upstream is
sufficient (kwrobot will complain about direct changes, but buildbot
doesn't care).

--Ben

From cory.quammen at kitware.com  Wed Jan 23 13:50:36 2019
From: cory.quammen at kitware.com (Cory Quammen)
Date: Wed, 23 Jan 2019 13:50:36 -0500
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
Message-ID: <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>

On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
>
> Meanwhile I see that discussion is still active on the dev mailing
> list. Shouldn't the VTK developers dogfood and use the Development
> category on Discourse now? :)

Yep, that's the idea for new developer topics. I think it makes sense
for existing discussions to be wrapped up on the mailing list for
archival purposes.

> Sorry, mostly joking. I'm one of the ones who are sad to see the
> mailing lists go, and the greater transition to Discourse, as my life
> is sort of built around my inbox :p I'll grudgingly accept defeat and
> register of course.

You can still use email! Albeit with some of the caveats mentioned in
the discussion leading up to this transition.

- Cory

>
> Elvis
>
> Den tis 22 jan. 2019 kl 19:28 skrev Andras Lasso <lasso at queensu.ca>:
> >
> > A soft transition worked quite nicely for both Slicer and ITK. For a while, questions sent to the mailing list were still answered there but a users were reminded that further questions should be posted to the forum. Then we stopped responding on the mailing list but asked people to post messages to discourse. Finally, we disabled posting to the list and set an auto-response message that explained that questions should be now posted on the forum. This transition was completed in a few months.
> >
> >
> >
> > It took a couple of months for google to start indexing the forum with high frequency and about a year to reach the same number of registered members as on the old mailing list.
> >
> >
> >
> > Andras
> >
> >
> >
> > From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Jan Hardenbergh
> > Sent: Tuesday, January 22, 2019 12:48 PM
> > To: vtkusers at vtk.org
> > Subject: [vtkusers] Transition to Discourse - thoughts from lurker
> >
> >
> >
> > There is a question here that has not really been addressed in the Welcome To Discourse page:
> >
> >  https://discourse.vtk.org/t/welcome-to-discourse/8
> >
> >
> >
> > Why should they come here?
> >
> >
> >
> > What is the motivation for the switch?
> >
> >
> >
> > If this will make it easier to provide support, that?s a good reason. A good transition strategy might be to reply to questions that are asked on the mailing list in Discourse, and then reply to the mailing list with the link.
> >
> >
> >
> > Another transition strategy would be to post the Topics Titles active for the past week to get people to go to Discourse if they are interested in that topic.
> >
> >
> >
> > Back to lurking?
> >
> > YON ? Jan C. Hardenbergh, VolumePro SW Eng. Mgr. Terarecon, Inc.
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://vtk.org/mailman/listinfo/vtkusers
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.

From elvis.stansvik at orexplore.com  Wed Jan 23 14:05:17 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Wed, 23 Jan 2019 20:05:17 +0100
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
Message-ID: <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>

Den ons 23 jan. 2019 kl 19:50 skrev Cory Quammen <cory.quammen at kitware.com>:
>
> On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
> >
> > Meanwhile I see that discussion is still active on the dev mailing
> > list. Shouldn't the VTK developers dogfood and use the Development
> > category on Discourse now? :)
>
> Yep, that's the idea for new developer topics. I think it makes sense
> for existing discussions to be wrapped up on the mailing list for
> archival purposes.
>
> > Sorry, mostly joking. I'm one of the ones who are sad to see the
> > mailing lists go, and the greater transition to Discourse, as my life
> > is sort of built around my inbox :p I'll grudgingly accept defeat and
> > register of course.
>
> You can still use email! Albeit with some of the caveats mentioned in
> the discussion leading up to this transition.

Yep, threw in some thoughts in that that thread (I think). I
participate some in other communities that have transitioned to
Discourse (e.g. HDF5), and it's a pain.. I can't collect all my
correspondence in one place anymore, marking/unmarking of stuff as
read etc., the mails from Discourse has a lot of cruft (buttons/links)
and the threading/replying inline doesn't work well. Also, if I reply
to a thread via the web UI, it'll show up as unread in my inbox
(naturally), which is annoying because I use that to keep an eye on
topics I follow. Also can't catch up on stuff while offline, which
occasionally do happen.

Wait, now I started a rambling when I promised myself not to do it :)
It's a community decision and I accept that. Perhaps the mail
integration will improve.

Elvis

>
> - Cory
>
> >
> > Elvis
> >
> > Den tis 22 jan. 2019 kl 19:28 skrev Andras Lasso <lasso at queensu.ca>:
> > >
> > > A soft transition worked quite nicely for both Slicer and ITK. For a while, questions sent to the mailing list were still answered there but a users were reminded that further questions should be posted to the forum. Then we stopped responding on the mailing list but asked people to post messages to discourse. Finally, we disabled posting to the list and set an auto-response message that explained that questions should be now posted on the forum. This transition was completed in a few months.
> > >
> > >
> > >
> > > It took a couple of months for google to start indexing the forum with high frequency and about a year to reach the same number of registered members as on the old mailing list.
> > >
> > >
> > >
> > > Andras
> > >
> > >
> > >
> > > From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Jan Hardenbergh
> > > Sent: Tuesday, January 22, 2019 12:48 PM
> > > To: vtkusers at vtk.org
> > > Subject: [vtkusers] Transition to Discourse - thoughts from lurker
> > >
> > >
> > >
> > > There is a question here that has not really been addressed in the Welcome To Discourse page:
> > >
> > >  https://discourse.vtk.org/t/welcome-to-discourse/8
> > >
> > >
> > >
> > > Why should they come here?
> > >
> > >
> > >
> > > What is the motivation for the switch?
> > >
> > >
> > >
> > > If this will make it easier to provide support, that?s a good reason. A good transition strategy might be to reply to questions that are asked on the mailing list in Discourse, and then reply to the mailing list with the link.
> > >
> > >
> > >
> > > Another transition strategy would be to post the Topics Titles active for the past week to get people to go to Discourse if they are interested in that topic.
> > >
> > >
> > >
> > > Back to lurking?
> > >
> > > YON ? Jan C. Hardenbergh, VolumePro SW Eng. Mgr. Terarecon, Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> > >
> > > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtkusers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://vtk.org/mailman/listinfo/vtkusers
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://vtk.org/mailman/listinfo/vtkusers
>
>
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.

From dan.lipsa at kitware.com  Wed Jan 23 14:17:18 2019
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Wed, 23 Jan 2019 14:17:18 -0500
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
Message-ID: <CADwGrVqa7ByYN9r7Ga-8x5K+C-q_2YNW_3qf4gHDswi+VJyb2g@mail.gmail.com>

Elvis,
We transition to Discourse for ParaView and I still receive and reply to
emails the same way as for mailing lists.

https://discourse.paraview.org/t/using-discourse-as-a-mailing-list/64



On Wed, Jan 23, 2019 at 2:05 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> Den ons 23 jan. 2019 kl 19:50 skrev Cory Quammen <cory.quammen at kitware.com
> >:
> >
> > On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
> > <elvis.stansvik at orexplore.com> wrote:
> > >
> > > Meanwhile I see that discussion is still active on the dev mailing
> > > list. Shouldn't the VTK developers dogfood and use the Development
> > > category on Discourse now? :)
> >
> > Yep, that's the idea for new developer topics. I think it makes sense
> > for existing discussions to be wrapped up on the mailing list for
> > archival purposes.
> >
> > > Sorry, mostly joking. I'm one of the ones who are sad to see the
> > > mailing lists go, and the greater transition to Discourse, as my life
> > > is sort of built around my inbox :p I'll grudgingly accept defeat and
> > > register of course.
> >
> > You can still use email! Albeit with some of the caveats mentioned in
> > the discussion leading up to this transition.
>
> Yep, threw in some thoughts in that that thread (I think). I
> participate some in other communities that have transitioned to
> Discourse (e.g. HDF5), and it's a pain.. I can't collect all my
> correspondence in one place anymore, marking/unmarking of stuff as
> read etc., the mails from Discourse has a lot of cruft (buttons/links)
> and the threading/replying inline doesn't work well. Also, if I reply
> to a thread via the web UI, it'll show up as unread in my inbox
> (naturally), which is annoying because I use that to keep an eye on
> topics I follow. Also can't catch up on stuff while offline, which
> occasionally do happen.
>
> Wait, now I started a rambling when I promised myself not to do it :)
> It's a community decision and I accept that. Perhaps the mail
> integration will improve.
>
> Elvis
>
> >
> > - Cory
> >
> > >
> > > Elvis
> > >
> > > Den tis 22 jan. 2019 kl 19:28 skrev Andras Lasso <lasso at queensu.ca>:
> > > >
> > > > A soft transition worked quite nicely for both Slicer and ITK. For a
> while, questions sent to the mailing list were still answered there but a
> users were reminded that further questions should be posted to the forum.
> Then we stopped responding on the mailing list but asked people to post
> messages to discourse. Finally, we disabled posting to the list and set an
> auto-response message that explained that questions should be now posted on
> the forum. This transition was completed in a few months.
> > > >
> > > >
> > > >
> > > > It took a couple of months for google to start indexing the forum
> with high frequency and about a year to reach the same number of registered
> members as on the old mailing list.
> > > >
> > > >
> > > >
> > > > Andras
> > > >
> > > >
> > > >
> > > > From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Jan
> Hardenbergh
> > > > Sent: Tuesday, January 22, 2019 12:48 PM
> > > > To: vtkusers at vtk.org
> > > > Subject: [vtkusers] Transition to Discourse - thoughts from lurker
> > > >
> > > >
> > > >
> > > > There is a question here that has not really been addressed in the
> Welcome To Discourse page:
> > > >
> > > >  https://discourse.vtk.org/t/welcome-to-discourse/8
> > > >
> > > >
> > > >
> > > > Why should they come here?
> > > >
> > > >
> > > >
> > > > What is the motivation for the switch?
> > > >
> > > >
> > > >
> > > > If this will make it easier to provide support, that?s a good
> reason. A good transition strategy might be to reply to questions that are
> asked on the mailing list in Discourse, and then reply to the mailing list
> with the link.
> > > >
> > > >
> > > >
> > > > Another transition strategy would be to post the Topics Titles
> active for the past week to get people to go to Discourse if they are
> interested in that topic.
> > > >
> > > >
> > > >
> > > > Back to lurking?
> > > >
> > > > YON ? Jan C. Hardenbergh, VolumePro SW Eng. Mgr. Terarecon, Inc.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Powered by www.kitware.com
> > > >
> > > > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> > > >
> > > > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> > > >
> > > > Search the list archives at: http://markmail.org/search/?q=vtkusers
> > > >
> > > > Follow this link to subscribe/unsubscribe:
> > > > https://vtk.org/mailman/listinfo/vtkusers
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> > >
> > > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtkusers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://vtk.org/mailman/listinfo/vtkusers
> >
> >
> >
> > --
> > Cory Quammen
> > Staff R&D Engineer
> > Kitware, Inc.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/a8d2ca3b/attachment-0001.html>

From marcus.hanwell at kitware.com  Wed Jan 23 14:24:42 2019
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Wed, 23 Jan 2019 14:24:42 -0500
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
Message-ID: <CAMkPkZXWO5PhGFUTWGx3HORuFRK17V2L2Vq07NY=ddZd7fkC5w@mail.gmail.com>

On Wed, Jan 23, 2019 at 2:05 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> Den ons 23 jan. 2019 kl 19:50 skrev Cory Quammen <cory.quammen at kitware.com
> >:
> >
> > On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
> > <elvis.stansvik at orexplore.com> wrote:
> > >
> > > Meanwhile I see that discussion is still active on the dev mailing
> > > list. Shouldn't the VTK developers dogfood and use the Development
> > > category on Discourse now? :)
> >
> > Yep, that's the idea for new developer topics. I think it makes sense
> > for existing discussions to be wrapped up on the mailing list for
> > archival purposes.
> >
> > > Sorry, mostly joking. I'm one of the ones who are sad to see the
> > > mailing lists go, and the greater transition to Discourse, as my life
> > > is sort of built around my inbox :p I'll grudgingly accept defeat and
> > > register of course.
> >
> > You can still use email! Albeit with some of the caveats mentioned in
> > the discussion leading up to this transition.
>
> Yep, threw in some thoughts in that that thread (I think). I
> participate some in other communities that have transitioned to
> Discourse (e.g. HDF5), and it's a pain.. I can't collect all my
> correspondence in one place anymore, marking/unmarking of stuff as
> read etc., the mails from Discourse has a lot of cruft (buttons/links)
> and the threading/replying inline doesn't work well. Also, if I reply
> to a thread via the web UI, it'll show up as unread in my inbox
> (naturally), which is annoying because I use that to keep an eye on
> topics I follow. Also can't catch up on stuff while offline, which
> occasionally do happen.
>
> Wait, now I started a rambling when I promised myself not to do it :)
> It's a community decision and I accept that. Perhaps the mail
> integration will improve.
>

I am trying to finish up some writing, and so procrastination made me check
the lists. I love and hate Discourse, there, I said it! The interface is
nice, and I think you can express more, fix typos, have richer
interactions, and provide a better thing to be indexed/viewed by others.

Discourse is still a pain for people that participate in many communities,
email is hard to beat for using the client you prefer, threading support,
having layers of communities you work with. I have a chemistry folder with
chemistry lists I am on within, a Kitware folder with Kitware related
communities, general lists folder for all the others.

Each of those subfolders is starting to become their own Discourse
instance, and it makes it harder for me to keep track of all of them, and
view them all from my mail client, replying with ease. I get the impression
that mailing lists are going the way of IRC :-) I am trying to adapt my
habits, but often miss notifications on threads I am taking part in, and
don't reply for weeks or more.

I suspect I need to develop new habits, spending a little time checking in
on Discourse instances I interact with every now and then, possibly
tweaking the notifications, and how I filter them in my email folder. I
genuinely prefer the added richness in discussion threads, I haven't tried
replying to Discourse stuff through email. Attending open source
conferences/workshops Discourse is improving engagement with newer
community members.

I think on balance it is a great step forward, but when something works
well for you (and me) it can feel like a waste of time changing it up. It
does us all good to learn new things, tangentially it has been fun to watch
the evolution of static web site, to server side includes, to Dreamweaver
et al, to PHP/MySQL content managers, to template-based static web sites. I
am a huge fan of Hugo, you can use GitHub for review, Travis to deploy, ...

I really should get back to writing ;-) Sad to see the demise of the lists,
and need to spend a little time retooling my habits around communication
with communities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/786fd5b4/attachment.html>

From sean at rogue-research.com  Wed Jan 23 14:27:03 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 14:27:03 -0500
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.c
 om>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTL
 OOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
Message-ID: <20190123192703.240096085@mail.rogue-research.com>

On Wed, 23 Jan 2019 20:05:17 +0100, Elvis Stansvik said:

>> You can still use email! Albeit with some of the caveats mentioned in
>> the discussion leading up to this transition.
>
>Yep, threw in some thoughts in that that thread (I think). I
>participate some in other communities that have transitioned to
>Discourse (e.g. HDF5), and it's a pain.

Yup, it's quite a lot worse. :(  Alas, I expect my participation will decrease because of it.

Sean



From sean at rogue-research.com  Wed Jan 23 14:42:07 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 14:42:07 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123184225.GA11145@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
Message-ID: <20190123194207.1151892642@mail.rogue-research.com>

On Wed, 23 Jan 2019 13:42:25 -0500, Ben Boeckel said:

>On Wed, Jan 23, 2019 at 11:48:00 -0500, Sean McBride wrote:
>> On Thu, 10 Jan 2019 17:07:12 -0500, Ben Boeckel via vtk-developers said:
>> >All third party warnings have been suppressed for now (though some may
>> >slip through yet). I'll deal with those in the future.
>> 
>> Any news on this?  My bot submissions have lots and lots of 3rd party
>> warnings...
>
>No, I haven't gotten to this yet. The vast majority are from one warning
>(redefinition of PRI64 or something), so fixing that one should help a
>lot. That should be fixed upstream and brought back into VTK though.
>There are others which should really be fixed upstream too.
>
>> (They didn't used to.)
>
>Well, we used to ignore all kinds of warnings on CDash (they still
>appeared in local builds though).

And is it your intention to not bring back this ignoring?

Getting all the many third party libs as warning-clean as VTK proper is a pretty Herculean task.  Meanwhile, all those third party warnings stop us from seeing VTK warnings.  If no one is doing the former, why should we lose the latter?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From lasso at queensu.ca  Wed Jan 23 14:42:30 2019
From: lasso at queensu.ca (Andras Lasso)
Date: Wed, 23 Jan 2019 19:42:30 +0000
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <20190123192703.240096085@mail.rogue-research.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.c
 om>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTL
 OOK.COM> <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
Message-ID: <YTOPR0101MB1292869D90D1589B532AB5CBD8990@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>

> the mails from Discourse has a lot of cruft (buttons/links)

The email template is fully configurable. Post your suggestions here: https://discourse.vtk.org/c/site-feedback

> I expect my participation will decrease because of it.

My experience is just the opposite. By setting up notifications properly, I only get emails about categories, topics, and keywords that I'm interested in, so I can follow activities of more communities.

Andras

-----Original Message-----
From: vtk-developers <vtk-developers-bounces at vtk.org> On Behalf Of Sean McBride
Sent: Wednesday, January 23, 2019 2:27 PM
To: Elvis Stansvik <elvis.stansvik at orexplore.com>; Cory Quammen <cory.quammen at kitware.com>
Cc: VTK Developers <vtk-developers at vtk.org>; vtkusers at vtk.org; Jan Hardenbergh <hardenbergh at terarecon.com>
Subject: Re: [vtk-developers] [vtkusers] Transition to Discourse - thoughts from lurker

On Wed, 23 Jan 2019 20:05:17 +0100, Elvis Stansvik said:

>> You can still use email! Albeit with some of the caveats mentioned in 
>> the discussion leading up to this transition.
>
>Yep, threw in some thoughts in that that thread (I think). I 
>participate some in other communities that have transitioned to 
>Discourse (e.g. HDF5), and it's a pain.

Yup, it's quite a lot worse. :(  Alas, I expect my participation will decrease because of it.

Sean


_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=Kk8du8Cl39%2BGubUpTrXB3LBnlPx%2FtlbgATXyk4U84Wg%3D&amp;reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=koBd7KQC2j8eXxwntmwO0pAjm%2FIuYngjJHb6rzI1XJQ%3D&amp;reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=vpPnvKyh90yr5UAO9vp%2FGY81eXuQCHfb8w0LnJ78rBk%3D&amp;reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvtk.org%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=FzonF%2FzS%2Bkl8ihwKcHnsKCfSeGpVw2GwuMB%2FvsDUoLM%3D&amp;reserved=0


From bill.lorensen at gmail.com  Wed Jan 23 14:50:26 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 23 Jan 2019 11:50:26 -0800
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
Message-ID: <CADZJ4hN1w7pB2T-91EuxabFA=_GeKTF4Txk+avxkfBTupzSTxg@mail.gmail.com>

I agree.

On Wed, Jan 23, 2019, 11:05 AM Elvis Stansvik <elvis.stansvik at orexplore.com
wrote:

> Den ons 23 jan. 2019 kl 19:50 skrev Cory Quammen <cory.quammen at kitware.com
> >:
> >
> > On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
> > <elvis.stansvik at orexplore.com> wrote:
> > >
> > > Meanwhile I see that discussion is still active on the dev mailing
> > > list. Shouldn't the VTK developers dogfood and use the Development
> > > category on Discourse now? :)
> >
> > Yep, that's the idea for new developer topics. I think it makes sense
> > for existing discussions to be wrapped up on the mailing list for
> > archival purposes.
> >
> > > Sorry, mostly joking. I'm one of the ones who are sad to see the
> > > mailing lists go, and the greater transition to Discourse, as my life
> > > is sort of built around my inbox :p I'll grudgingly accept defeat and
> > > register of course.
> >
> > You can still use email! Albeit with some of the caveats mentioned in
> > the discussion leading up to this transition.
>
> Yep, threw in some thoughts in that that thread (I think). I
> participate some in other communities that have transitioned to
> Discourse (e.g. HDF5), and it's a pain.. I can't collect all my
> correspondence in one place anymore, marking/unmarking of stuff as
> read etc., the mails from Discourse has a lot of cruft (buttons/links)
> and the threading/replying inline doesn't work well. Also, if I reply
> to a thread via the web UI, it'll show up as unread in my inbox
> (naturally), which is annoying because I use that to keep an eye on
> topics I follow. Also can't catch up on stuff while offline, which
> occasionally do happen.
>
> Wait, now I started a rambling when I promised myself not to do it :)
> It's a community decision and I accept that. Perhaps the mail
> integration will improve.
>
> Elvis
>
> >
> > - Cory
> >
> > >
> > > Elvis
> > >
> > > Den tis 22 jan. 2019 kl 19:28 skrev Andras Lasso <lasso at queensu.ca>:
> > > >
> > > > A soft transition worked quite nicely for both Slicer and ITK. For a
> while, questions sent to the mailing list were still answered there but a
> users were reminded that further questions should be posted to the forum.
> Then we stopped responding on the mailing list but asked people to post
> messages to discourse. Finally, we disabled posting to the list and set an
> auto-response message that explained that questions should be now posted on
> the forum. This transition was completed in a few months.
> > > >
> > > >
> > > >
> > > > It took a couple of months for google to start indexing the forum
> with high frequency and about a year to reach the same number of registered
> members as on the old mailing list.
> > > >
> > > >
> > > >
> > > > Andras
> > > >
> > > >
> > > >
> > > > From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Jan
> Hardenbergh
> > > > Sent: Tuesday, January 22, 2019 12:48 PM
> > > > To: vtkusers at vtk.org
> > > > Subject: [vtkusers] Transition to Discourse - thoughts from lurker
> > > >
> > > >
> > > >
> > > > There is a question here that has not really been addressed in the
> Welcome To Discourse page:
> > > >
> > > >  https://discourse.vtk.org/t/welcome-to-discourse/8
> > > >
> > > >
> > > >
> > > > Why should they come here?
> > > >
> > > >
> > > >
> > > > What is the motivation for the switch?
> > > >
> > > >
> > > >
> > > > If this will make it easier to provide support, that?s a good
> reason. A good transition strategy might be to reply to questions that are
> asked on the mailing list in Discourse, and then reply to the mailing list
> with the link.
> > > >
> > > >
> > > >
> > > > Another transition strategy would be to post the Topics Titles
> active for the past week to get people to go to Discourse if they are
> interested in that topic.
> > > >
> > > >
> > > >
> > > > Back to lurking?
> > > >
> > > > YON ? Jan C. Hardenbergh, VolumePro SW Eng. Mgr. Terarecon, Inc.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Powered by www.kitware.com
> > > >
> > > > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> > > >
> > > > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> > > >
> > > > Search the list archives at: http://markmail.org/search/?q=vtkusers
> > > >
> > > > Follow this link to subscribe/unsubscribe:
> > > > https://vtk.org/mailman/listinfo/vtkusers
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> > >
> > > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> > >
> > > Search the list archives at: http://markmail.org/search/?q=vtkusers
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > https://vtk.org/mailman/listinfo/vtkusers
> >
> >
> >
> > --
> > Cory Quammen
> > Staff R&D Engineer
> > Kitware, Inc.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/47a855d9/attachment-0001.html>

From bill.lorensen at gmail.com  Wed Jan 23 14:52:26 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 23 Jan 2019 11:52:26 -0800
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <20190123192703.240096085@mail.rogue-research.com>
References: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
Message-ID: <CADZJ4hPu1r0X7KsjrZfvNq4K7-o2OJDNxthTcpsRf_f-HKJvGQ@mail.gmail.com>

Sean,

Email works for me vis discourse. Please don't reduce your participation.

We need you.

Bill

On Wed, Jan 23, 2019, 11:27 AM Sean McBride <sean at rogue-research.com wrote:

> On Wed, 23 Jan 2019 20:05:17 +0100, Elvis Stansvik said:
>
> >> You can still use email! Albeit with some of the caveats mentioned in
> >> the discussion leading up to this transition.
> >
> >Yep, threw in some thoughts in that that thread (I think). I
> >participate some in other communities that have transitioned to
> >Discourse (e.g. HDF5), and it's a pain.
>
> Yup, it's quite a lot worse. :(  Alas, I expect my participation will
> decrease because of it.
>
> Sean
>
>
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/43a96494/attachment.html>

From ben.boeckel at kitware.com  Wed Jan 23 14:58:29 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 14:58:29 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123194207.1151892642@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
Message-ID: <20190123195829.GA4158@megas.kitware.com>

On Wed, Jan 23, 2019 at 14:42:07 -0500, Sean McBride wrote:
> And is it your intention to not bring back this ignoring?

If there are warnings we cannot otherwise fix, yes.

> Getting all the many third party libs as warning-clean as VTK proper
> is a pretty Herculean task.  Meanwhile, all those third party warnings
> stop us from seeing VTK warnings.  If no one is doing the former, why
> should we lose the latter?

Looking at the warnings for one of the rogue machines:

    https://open.cdash.org/viewBuildError.php?type=1&buildid=5719051

it looks like, we just need to ignore the `[0-9]* warnings? generated`
regex to exclude those that are matched yet. Does adding that to
`CMake/CTestCustom.cmake.in` (in the general section), help with the
output?

--Ben

From elvis.stansvik at orexplore.com  Wed Jan 23 15:15:43 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Wed, 23 Jan 2019 21:15:43 +0100
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CAMkPkZXWO5PhGFUTWGx3HORuFRK17V2L2Vq07NY=ddZd7fkC5w@mail.gmail.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <CAMkPkZXWO5PhGFUTWGx3HORuFRK17V2L2Vq07NY=ddZd7fkC5w@mail.gmail.com>
Message-ID: <CAE-7VJ=RwM6wBS6jwgzPryJAYMTS0w-wABvQnZiTJLUTsjiHNA@mail.gmail.com>

Den ons 23 jan. 2019 kl 20:24 skrev Marcus D. Hanwell
<marcus.hanwell at kitware.com>:
>
> On Wed, Jan 23, 2019 at 2:05 PM Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
>>
>> Den ons 23 jan. 2019 kl 19:50 skrev Cory Quammen <cory.quammen at kitware.com>:
>> >
>> > On Wed, Jan 23, 2019 at 1:46 PM Elvis Stansvik
>> > <elvis.stansvik at orexplore.com> wrote:
>> > >
>> > > Meanwhile I see that discussion is still active on the dev mailing
>> > > list. Shouldn't the VTK developers dogfood and use the Development
>> > > category on Discourse now? :)
>> >
>> > Yep, that's the idea for new developer topics. I think it makes sense
>> > for existing discussions to be wrapped up on the mailing list for
>> > archival purposes.
>> >
>> > > Sorry, mostly joking. I'm one of the ones who are sad to see the
>> > > mailing lists go, and the greater transition to Discourse, as my life
>> > > is sort of built around my inbox :p I'll grudgingly accept defeat and
>> > > register of course.
>> >
>> > You can still use email! Albeit with some of the caveats mentioned in
>> > the discussion leading up to this transition.
>>
>> Yep, threw in some thoughts in that that thread (I think). I
>> participate some in other communities that have transitioned to
>> Discourse (e.g. HDF5), and it's a pain.. I can't collect all my
>> correspondence in one place anymore, marking/unmarking of stuff as
>> read etc., the mails from Discourse has a lot of cruft (buttons/links)
>> and the threading/replying inline doesn't work well. Also, if I reply
>> to a thread via the web UI, it'll show up as unread in my inbox
>> (naturally), which is annoying because I use that to keep an eye on
>> topics I follow. Also can't catch up on stuff while offline, which
>> occasionally do happen.
>>
>> Wait, now I started a rambling when I promised myself not to do it :)
>> It's a community decision and I accept that. Perhaps the mail
>> integration will improve.
>
>
> I am trying to finish up some writing, and so procrastination made me check the lists. I love and hate Discourse, there, I said it! The interface is nice, and I think you can express more, fix typos, have richer interactions, and provide a better thing to be indexed/viewed by others.
>
> Discourse is still a pain for people that participate in many communities, email is hard to beat for using the client you prefer, threading support, having layers of communities you work with. I have a chemistry folder with chemistry lists I am on within, a Kitware folder with Kitware related communities, general lists folder for all the others.
>
> Each of those subfolders is starting to become their own Discourse instance, and it makes it harder for me to keep track of all of them, and view them all from my mail client, replying with ease. I get the impression that mailing lists are going the way of IRC :-) I am trying to adapt my habits, but often miss notifications on threads I am taking part in, and don't reply for weeks or more.
>
> I suspect I need to develop new habits, spending a little time checking in on Discourse instances I interact with every now and then, possibly tweaking the notifications, and how I filter them in my email folder. I genuinely prefer the added richness in discussion threads, I haven't tried replying to Discourse stuff through email. Attending open source conferences/workshops Discourse is improving engagement with newer community members.
>
> I think on balance it is a great step forward, but when something works well for you (and me) it can feel like a waste of time changing it up. It does us all good to learn new things, tangentially it has been fun to watch the evolution of static web site, to server side includes, to Dreamweaver et al, to PHP/MySQL content managers, to template-based static web sites. I am a huge fan of Hugo, you can use GitHub for review, Travis to deploy, ...
>
> I really should get back to writing ;-) Sad to see the demise of the lists, and need to spend a little time retooling my habits around communication with communities.

Yes, all good thoughts Marcus. I feel much the same.

Elvis

From sean at rogue-research.com  Wed Jan 23 15:24:44 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 15:24:44 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123195829.GA4158@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
 <20190123195829.GA4158@megas.kitware.com>
Message-ID: <20190123202444.1582821286@mail.rogue-research.com>

On Wed, 23 Jan 2019 14:58:29 -0500, Ben Boeckel said:

>On Wed, Jan 23, 2019 at 14:42:07 -0500, Sean McBride wrote:
>> And is it your intention to not bring back this ignoring?
>
>If there are warnings we cannot otherwise fix, yes.
>
>> Getting all the many third party libs as warning-clean as VTK proper
>> is a pretty Herculean task.  Meanwhile, all those third party warnings
>> stop us from seeing VTK warnings.  If no one is doing the former, why
>> should we lose the latter?
>
>Looking at the warnings for one of the rogue machines:
>
>    https://open.cdash.org/viewBuildError.php?type=1&buildid=5719051
>
>it looks like, we just need to ignore the `[0-9]* warnings? generated`
>regex to exclude those that are matched yet. 

So for example:

[CTest: warning suppressed] /Users/builder/external/VTK/ThirdParty/libproj/vtklibproj/src/projects.h:609:25: warning: this function declaration is not a prototype [-Wstrict-prototypes]
void pj_deallocate_grids();
                        ^
                         void
[CTest: warning matched] 2 warnings generated.

I hadn't noticed the "CTest: warning suppressed/matched" part... you're saying it's the 'matched' part that's making all the rest appear too?

>Does adding that to
>`CMake/CTestCustom.cmake.in` (in the general section), help with the
>output?

I'll try an Experimental submission...

Sean



From elvis.stansvik at orexplore.com  Wed Jan 23 15:45:33 2019
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Wed, 23 Jan 2019 21:45:33 +0100
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <YTOPR0101MB1292869D90D1589B532AB5CBD8990@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
References: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
 <YTOPR0101MB1292869D90D1589B532AB5CBD8990@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <CAE-7VJkOG9GcuGKO54BRUmFbbNkVSq8t7dUbhx7n8Ao+hdnnrQ@mail.gmail.com>

Den ons 23 jan. 2019 kl 20:42 skrev Andras Lasso <lasso at queensu.ca>:
>
> > the mails from Discourse has a lot of cruft (buttons/links)
>
> The email template is fully configurable. Post your suggestions here: https://discourse.vtk.org/c/site-feedback

Ah, great idea, I made a post:
https://discourse.vtk.org/t/customize-the-e-mail-template/109

Elvis

>
> > I expect my participation will decrease because of it.
>
> My experience is just the opposite. By setting up notifications properly, I only get emails about categories, topics, and keywords that I'm interested in, so I can follow activities of more communities.
>
> Andras
>
> -----Original Message-----
> From: vtk-developers <vtk-developers-bounces at vtk.org> On Behalf Of Sean McBride
> Sent: Wednesday, January 23, 2019 2:27 PM
> To: Elvis Stansvik <elvis.stansvik at orexplore.com>; Cory Quammen <cory.quammen at kitware.com>
> Cc: VTK Developers <vtk-developers at vtk.org>; vtkusers at vtk.org; Jan Hardenbergh <hardenbergh at terarecon.com>
> Subject: Re: [vtk-developers] [vtkusers] Transition to Discourse - thoughts from lurker
>
> On Wed, 23 Jan 2019 20:05:17 +0100, Elvis Stansvik said:
>
> >> You can still use email! Albeit with some of the caveats mentioned in
> >> the discussion leading up to this transition.
> >
> >Yep, threw in some thoughts in that that thread (I think). I
> >participate some in other communities that have transitioned to
> >Discourse (e.g. HDF5), and it's a pain.
>
> Yup, it's quite a lot worse. :(  Alas, I expect my participation will decrease because of it.
>
> Sean
>
>
> _______________________________________________
> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=Kk8du8Cl39%2BGubUpTrXB3LBnlPx%2FtlbgATXyk4U84Wg%3D&amp;reserved=0
>
> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=koBd7KQC2j8eXxwntmwO0pAjm%2FIuYngjJHb6rzI1XJQ%3D&amp;reserved=0
>
> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=vpPnvKyh90yr5UAO9vp%2FGY81eXuQCHfb8w0LnJ78rBk%3D&amp;reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvtk.org%2Fmailman%2Flistinfo%2Fvtk-developers&amp;data=02%7C01%7Classo%40queensu.ca%7C549da3416ccb44ea4e3e08d68168c516%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838684322414316&amp;sdata=FzonF%2FzS%2Bkl8ihwKcHnsKCfSeGpVw2GwuMB%2FvsDUoLM%3D&amp;reserved=0
>

From ben.boeckel at kitware.com  Wed Jan 23 15:56:24 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 15:56:24 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123202444.1582821286@mail.rogue-research.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
 <20190123195829.GA4158@megas.kitware.com>
 <20190123202444.1582821286@mail.rogue-research.com>
Message-ID: <20190123205624.GA23598@megas.kitware.com>

On Wed, Jan 23, 2019 at 15:24:44 -0500, Sean McBride wrote:
> So for example:
> 
> [CTest: warning suppressed] /Users/builder/external/VTK/ThirdParty/libproj/vtklibproj/src/projects.h:609:25: warning: this function declaration is not a prototype [-Wstrict-prototypes]
> void pj_deallocate_grids();
>                         ^
>                          void
> [CTest: warning matched] 2 warnings generated.
> 
> I hadn't noticed the "CTest: warning suppressed/matched" part... you're saying it's the 'matched' part that's making all the rest appear too?

Yes. CTest/CDash is confusing sometimes :( . That output helps *a lot*
though since before you had to guess what was making the block show up.

> I'll try an Experimental submission...

Thanks.

--Ben

From sean at rogue-research.com  Wed Jan 23 16:19:04 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 16:19:04 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123205624.GA23598@megas.kitware.com>
References: <20190102192353.GA24527@rotor.localdomain>
 <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
 <20190123195829.GA4158@megas.kitware.com>
 <20190123202444.1582821286@mail.rogue-research.com>
 <20190123205624.GA23598@megas.kitware.com>
Message-ID: <20190123211904.575471262@mail.rogue-research.com>

On Wed, 23 Jan 2019 15:56:24 -0500, Ben Boeckel said:

>On Wed, Jan 23, 2019 at 15:24:44 -0500, Sean McBride wrote:
>> So for example:
>> 
>> [CTest: warning suppressed] /Users/builder/external/VTK/ThirdParty/
>libproj/vtklibproj/src/projects.h:609:25: warning: this function
>declaration is not a prototype [-Wstrict-prototypes]
>> void pj_deallocate_grids();
>>                         ^
>>                          void
>> [CTest: warning matched] 2 warnings generated.
>> 
>> I hadn't noticed the "CTest: warning suppressed/matched" part...
>you're saying it's the 'matched' part that's making all the rest appear too?
>
>Yes. CTest/CDash is confusing sometimes :( . That output helps *a lot*
>though since before you had to guess what was making the block show up.
>
>> I'll try an Experimental submission...
>
>Thanks.

I think that did help, see:
<https://open.cdash.org/viewBuildError.php?type=1&buildid=5720161>

So I guess therefore we'd also want to match:

[CTest: warning matched] note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)

?

Sean



From pdhahn at compintensehpc.com  Wed Jan 23 15:43:28 2019
From: pdhahn at compintensehpc.com (Paul Douglas Hahn)
Date: Wed, 23 Jan 2019 14:43:28 -0600
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <20190123192703.240096085@mail.rogue-research.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.c
 om>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTL
 OOK.COM> <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
Message-ID: <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>

I realize I am not an important voice for this topic, but with 
Discourse, I can say that I anticipate termination of "real-time" 
monitoring of VTK issues that I now do with the mailing lists. I do not 
want to be on a "free" community site that is or might become oriented 
to make money of me one way or another (hidden), tracking me, etc. etc.

Hmmm ... so how long will it take Microsoft to come in and buy Discourse 
just like they did with Github? And what is the relationship (if any) 
between Bloomberg's Discourse Analytics (www.discourseanalytics.com) and 
Discourse.org? They both have similar logos. Just wondering.

Bye,
Paul

On 1/23/19 1:27 PM, Sean McBride wrote:
> On Wed, 23 Jan 2019 20:05:17 +0100, Elvis Stansvik said:
>
>>> You can still use email! Albeit with some of the caveats mentioned in
>>> the discussion leading up to this transition.
>> Yep, threw in some thoughts in that that thread (I think). I
>> participate some in other communities that have transitioned to
>> Discourse (e.g. HDF5), and it's a pain.
> Yup, it's quite a lot worse. :(  Alas, I expect my participation will decrease because of it.
>
> Sean
>
>
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>

-- 



From david.gobbi at gmail.com  Wed Jan 23 17:03:03 2019
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 23 Jan 2019 15:03:03 -0700
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
References: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
 <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
Message-ID: <CANwS1=EmnUf9MPo=kQuEfmYch4ez9c6upZ-LJJGmy4REBZHz6w@mail.gmail.com>

Hi Paul,

As far as I understand, Kitware is running Discourse on their own server.
So even if it is bought out, Kitware can continue to use the version that
they currently have and fork/patch it as necessary.  And I'm sure that if
anyone audits the Discourse code base and finds that it is leaking
analytics to someone, Kitware would be happy to plug the leak.

In any case, there's plenty of analytics that companies can do based on
public mailing lists, and I don't think a public forum is any different in
that regard unless you include confidential info in your profile.

  David


On Wed, Jan 23, 2019 at 2:25 PM Paul Douglas Hahn <pdhahn at compintensehpc.com>
wrote:

> I realize I am not an important voice for this topic, but with
> Discourse, I can say that I anticipate termination of "real-time"
> monitoring of VTK issues that I now do with the mailing lists. I do not
> want to be on a "free" community site that is or might become oriented
> to make money of me one way or another (hidden), tracking me, etc. etc.
>
> Hmmm ... so how long will it take Microsoft to come in and buy Discourse
> just like they did with Github? And what is the relationship (if any)
> between Bloomberg's Discourse Analytics (www.discourseanalytics.com) and
> Discourse.org? They both have similar logos. Just wondering.
>
> Bye,
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/06b0e045/attachment.html>

From ben.boeckel at kitware.com  Wed Jan 23 17:15:32 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 17:15:32 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123211904.575471262@mail.rogue-research.com>
References: <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
 <20190123195829.GA4158@megas.kitware.com>
 <20190123202444.1582821286@mail.rogue-research.com>
 <20190123205624.GA23598@megas.kitware.com>
 <20190123211904.575471262@mail.rogue-research.com>
Message-ID: <20190123221532.GA28532@megas.kitware.com>

On Wed, Jan 23, 2019 at 16:19:04 -0500, Sean McBride wrote:
> I think that did help, see:
> <https://open.cdash.org/viewBuildError.php?type=1&buildid=5720161>
> 
> So I guess therefore we'd also want to match:
> 
> [CTest: warning matched] note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)

Yeah, something like:

    note: \\(skipping [0-9]* expansions in backtrace

?

I also see:

    note: expanded from here
    note: expanded from macro

Note that MetaIO is a Kitware project (it is shared ITK/VTK code), so
fixing the nullptr warnings would be pretty easy to upstream. Upstream
already assumes C++11 too.

--Ben

From ben.boeckel at kitware.com  Wed Jan 23 17:17:13 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 23 Jan 2019 17:17:13 -0500
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
References: <BN6PR08MB3586EC65EE1A756404729C76AC980@BN6PR08MB3586.namprd08.prod.outlook.com>
 <YTOPR0101MB1292A115BA70B64E0464044BD8980@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>
 <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
 <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
Message-ID: <20190123221713.GB28532@megas.kitware.com>

On Wed, Jan 23, 2019 at 14:43:28 -0600, Paul Douglas Hahn wrote:
> I realize I am not an important voice for this topic, but with 
> Discourse, I can say that I anticipate termination of "real-time" 
> monitoring of VTK issues that I now do with the mailing lists. I do not 
> want to be on a "free" community site that is or might become oriented 
> to make money of me one way or another (hidden), tracking me, etc. etc.

Off topic, but I recommend an adblocker since much of the Web is doing
that. However...

> Hmmm ... so how long will it take Microsoft to come in and buy Discourse 
> just like they did with Github? And what is the relationship (if any) 
> between Bloomberg's Discourse Analytics (www.discourseanalytics.com) and 
> Discourse.org? They both have similar logos. Just wondering.

we use our own Discourse hosting; it isn't on discourse.org, so
Microsoft buying it wouldn't affect our deployment (directly).

--Ben

From pdhahn at compintensehpc.com  Wed Jan 23 17:22:25 2019
From: pdhahn at compintensehpc.com (Paul Douglas Hahn)
Date: Wed, 23 Jan 2019 16:22:25 -0600
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <CANwS1=EmnUf9MPo=kQuEfmYch4ez9c6upZ-LJJGmy4REBZHz6w@mail.gmail.com>
References: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
 <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
 <CANwS1=EmnUf9MPo=kQuEfmYch4ez9c6upZ-LJJGmy4REBZHz6w@mail.gmail.com>
Message-ID: <b7b7c45a-1510-0261-8e81-4a8d986fa20e@compintensehpc.com>

OK, thanks for that. Sounds more innocuous.

As a remark, I believe that the quality of analytic products done on 
mailing lists is far less than that which can be done on community sites 
with engines in the middle, especially for one reason: the latter allows 
tracking message /reads/ in detail, and moreover, /who/ does the reads 
(vs. who does not), and what are the characteristics. All this to 
formulate rich feature vectors for ANN training. I believe that that is 
not feasible with mailing lists, but I may be wrong. And of course, it's 
easy enough to correlate names to confidential info already snarfed into 
the world of databases out there.

- Paul

On 1/23/19 4:03 PM, David Gobbi wrote:
> Hi Paul,
>
> As far as I understand, Kitware is running Discourse on their own 
> server.? So even if it is bought out, Kitware can continue to use the 
> version that they currently have and fork/patch it as necessary.? And 
> I'm sure that if anyone audits the Discourse code base and finds that 
> it is leaking analytics to someone, Kitware would be happy to plug the 
> leak.
>
> In any case, there's plenty of analytics that companies can do based 
> on public mailing lists, and I don't think a public forum is any 
> different in that regard unless you include confidential info in your 
> profile.
>
> ? David
>
>
> On Wed, Jan 23, 2019 at 2:25 PM Paul Douglas Hahn 
> <pdhahn at compintensehpc.com <mailto:pdhahn at compintensehpc.com>> wrote:
>
>     I realize I am not an important voice for this topic, but with
>     Discourse, I can say that I anticipate termination of "real-time"
>     monitoring of VTK issues that I now do with the mailing lists. I
>     do not
>     want to be on a "free" community site that is or might become
>     oriented
>     to make money of me one way or another (hidden), tracking me, etc.
>     etc.
>
>     Hmmm ... so how long will it take Microsoft to come in and buy
>     Discourse
>     just like they did with Github? And what is the relationship (if any)
>     between Bloomberg's Discourse Analytics
>     (www.discourseanalytics.com <http://www.discourseanalytics.com>) and
>     Discourse.org? They both have similar logos. Just wondering.
>
>     Bye,
>     Paul
>

-- 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/57802071/attachment-0001.html>

From lasso at queensu.ca  Wed Jan 23 17:55:13 2019
From: lasso at queensu.ca (Andras Lasso)
Date: Wed, 23 Jan 2019 22:55:13 +0000
Subject: [vtk-developers] [vtkusers] Transition to Discourse - thoughts
 from lurker
In-Reply-To: <b7b7c45a-1510-0261-8e81-4a8d986fa20e@compintensehpc.com>
References: <CAE-7VJmPUjcr8bzG4HkA3kw79G==JJte=Vkg7SWYjfT57py5SQ@mail.gmail.com>
 <CAB5Fpx4uS9+oqBE_6eeKMtE6HRXTxM=4ODbefbXwGA_a6K2hkQ@mail.gmail.com>
 <CAE-7VJnv9jGWoP++CNtun+HiYr8ZP42ZorWDw7RNbqhTRXeNQA@mail.gmail.com>
 <20190123192703.240096085@mail.rogue-research.com>
 <476a00e8-69b6-c209-dd65-7edc3820b035@compintensehpc.com>
 <CANwS1=EmnUf9MPo=kQuEfmYch4ez9c6upZ-LJJGmy4REBZHz6w@mail.gmail.com>
 <b7b7c45a-1510-0261-8e81-4a8d986fa20e@compintensehpc.com>
Message-ID: <YTOPR0101MB1292CD3C0375CE4FFDE13A92D8990@YTOPR0101MB1292.CANPRD01.PROD.OUTLOOK.COM>

Full content of VTK mailing lists, names, email addresses have been already publicly available on the web (http://vtk.1045678.n5.nabble.com/, https://vtk.org/pipermail/vtkusers/, etc).

However, spammers don?t even need to harvest email addresses one by one. It is enough if a spammer subscribes to any of the VTK mailing list (there is no sophisticated anti-spam measures) and he gets access to email addresses of all the other subscribers. See for example the 3000+ email addresses listed at https://vtk.org/mailman/roster/vtkusers:

[cid:image001.png at 01D4B342.4BFD6C60]


On discourse your email address is never publicly disclosed and many spam countermeasures are implemented. If you have privacy or security concerns then you should welcome the switch to discourse.

Andras


From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Paul Douglas Hahn
Sent: Wednesday, January 23, 2019 5:22 PM
To: David Gobbi <david.gobbi at gmail.com>
Cc: VTK Developers <vtk-developers at vtk.org>; VTK Users <vtkusers at vtk.org>
Subject: Re: [vtkusers] [vtk-developers] Transition to Discourse - thoughts from lurker

OK, thanks for that. Sounds more innocuous.

As a remark, I believe that the quality of analytic products done on mailing lists is far less than that which can be done on community sites with engines in the middle, especially for one reason: the latter allows tracking message reads in detail, and moreover, who does the reads (vs. who does not), and what are the characteristics. All this to formulate rich feature vectors for ANN training. I believe that that is not feasible with mailing lists, but I may be wrong. And of course, it's easy enough to correlate names to confidential info already snarfed into the world of databases out there.

- Paul
On 1/23/19 4:03 PM, David Gobbi wrote:
Hi Paul,

As far as I understand, Kitware is running Discourse on their own server.  So even if it is bought out, Kitware can continue to use the version that they currently have and fork/patch it as necessary.  And I'm sure that if anyone audits the Discourse code base and finds that it is leaking analytics to someone, Kitware would be happy to plug the leak.

In any case, there's plenty of analytics that companies can do based on public mailing lists, and I don't think a public forum is any different in that regard unless you include confidential info in your profile.

  David


On Wed, Jan 23, 2019 at 2:25 PM Paul Douglas Hahn <pdhahn at compintensehpc.com<mailto:pdhahn at compintensehpc.com>> wrote:
I realize I am not an important voice for this topic, but with
Discourse, I can say that I anticipate termination of "real-time"
monitoring of VTK issues that I now do with the mailing lists. I do not
want to be on a "free" community site that is or might become oriented
to make money of me one way or another (hidden), tracking me, etc. etc.

Hmmm ... so how long will it take Microsoft to come in and buy Discourse
just like they did with Github? And what is the relationship (if any)
between Bloomberg's Discourse Analytics (www.discourseanalytics.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.discourseanalytics.com&data=02%7C01%7Classo%40queensu.ca%7C9b4e04e5fb5d4ff4395908d68181453e%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636838789558842462&sdata=0N5PPRyO0%2Bt0kAYFmuZZ3x71mnF1VGYHkaV1iamvhmg%3D&reserved=0>) and
Discourse.org? They both have similar logos. Just wondering.

Bye,
Paul



--




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/c112930b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 106194 bytes
Desc: image001.png
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190123/c112930b/attachment-0001.png>

From sean at rogue-research.com  Wed Jan 23 20:28:25 2019
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 23 Jan 2019 20:28:25 -0500
Subject: [vtk-developers] [ANNOUNCE] New module system landing
In-Reply-To: <20190123221532.GA28532@megas.kitware.com>
References: <20190108165648.GA24126@megas.kitware.com>
 <20190108231154.GA29838@megas.kitware.com>
 <20190110220712.GA21739@megas.kitware.com>
 <20190123164800.1354162260@mail.rogue-research.com>
 <20190123184225.GA11145@megas.kitware.com>
 <20190123194207.1151892642@mail.rogue-research.com>
 <20190123195829.GA4158@megas.kitware.com>
 <20190123202444.1582821286@mail.rogue-research.com>
 <20190123205624.GA23598@megas.kitware.com>
 <20190123211904.575471262@mail.rogue-research.com>
 <20190123221532.GA28532@megas.kitware.com>
Message-ID: <20190124012825.629502722@mail.rogue-research.com>

On Wed, 23 Jan 2019 17:15:32 -0500, Ben Boeckel said:

>On Wed, Jan 23, 2019 at 16:19:04 -0500, Sean McBride wrote:
>> I think that did help, see:
>> <https://open.cdash.org/viewBuildError.php?type=1&buildid=5720161>
>> 
>> So I guess therefore we'd also want to match:
>> 
>> [CTest: warning matched] note: (skipping 2 expansions in backtrace;
>use -fmacro-backtrace-limit=0 to see all)
>
>Yeah, something like:
>
>    note: \\(skipping [0-9]* expansions in backtrace
>
>?
>
>I also see:
>
>    note: expanded from here
>    note: expanded from macro

Hopefully I've done this right:
<https://gitlab.kitware.com/vtk/vtk/merge_requests/5100>

>Note that MetaIO is a Kitware project (it is shared ITK/VTK code), so
>fixing the nullptr warnings would be pretty easy to upstream.

I did that a week or two ago. :)

>Upstream already assumes C++11 too.

Yeah, that was me too. :)

Cheers,

Sean



From cory.quammen at kitware.com  Fri Jan 25 16:24:19 2019
From: cory.quammen at kitware.com (Cory Quammen)
Date: Fri, 25 Jan 2019 16:24:19 -0500
Subject: [vtk-developers] Top VTK Discourse topics for the past week
Message-ID: <CAB5Fpx4DXvQvmCf0dsYqNNnsw2x+bNthJtf7GBk2LRxX5yeiKw@mail.gmail.com>

If you haven't registered for VTK's Discourse forum yet, here's a summary
of this week's top topics posted on https://discourse.vtk.org:

demystifiying color discretization
<https://discourse.vtk.org/t/demystifiying-color-discretization/117>

Proposal to add orientation to vtkImageData- Feedback Wanted
<https://discourse.vtk.org/t/proposal-to-add-orientation-to-vtkimagedata-feedback-wanted/120>

Customize the e-mail template?
<https://discourse.vtk.org/t/customize-the-e-mail-template/109>

Using Discourse as a mailing list
<https://discourse.vtk.org/t/using-discourse-as-a-mailing-list/53>

Unable to build INSTALL using VTK master on Visual Studio 2015
<https://discourse.vtk.org/t/unable-to-build-install-using-vtk-master-on-visual-studio-2015/98>

vtkIOGDAL and vtkIOGeoJSON
<https://discourse.vtk.org/t/vtkiogdal-and-vtkiogeojson/103>

Interpolating points and direction along a path in 3D space
<https://discourse.vtk.org/t/interpolating-points-and-direction-along-a-path-in-3d-space/115>

Modularization dashboard cleanup
<https://discourse.vtk.org/t/modularization-dashboard-cleanup/125>

Scaling tube radius by distance to camera
<https://discourse.vtk.org/t/scaling-tube-radius-by-distance-to-camera/95>

Free Biomedical Image Analysis and Visualization 3-day Course
<https://discourse.vtk.org/t/free-biomedical-image-analysis-and-visualization-3-day-course/88>

segfault for python importing vtk but not for vtkpython
<https://discourse.vtk.org/t/segfault-for-python-importing-vtk-but-not-for-vtkpython/126>

Arbitary Order Lagrange Hexahedron Connectivity
<https://discourse.vtk.org/t/arbitary-order-lagrange-hexahedron-connectivity/76>

Scroll through 2d slices of 3d volume - ultrasound .mhd file
<https://discourse.vtk.org/t/scroll-through-2d-slices-of-3d-volume-ultrasound-mhd-file/102>

Unable to build vtkAcceleratorsVTKm with CUDA using VTK Release on Visual
Studio 2015 / Windows 10
<https://discourse.vtk.org/t/unable-to-build-vtkacceleratorsvtkm-with-cuda-using-vtk-release-on-visual-studio-2015-windows-10/133>

A good strategy to label a particular point of a vtkPolyData (or display a
something near it)
<https://discourse.vtk.org/t/a-good-strategy-to-label-a-particular-point-of-a-vtkpolydata-or-display-a-something-near-it/134>

Point data from `vtkProbeFilter` lost after `vtkSelectEnclosedPoints`
<https://discourse.vtk.org/t/point-data-from-vtkprobefilter-lost-after-vtkselectenclosedpoints/130>

removing added texture from actor
<https://discourse.vtk.org/t/removing-added-texture-from-actor/137>

How to let vtkScalarBar showing marks for Text Annotation?
<https://discourse.vtk.org/t/how-to-let-vtkscalarbar-showing-marks-for-text-annotation/131>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190125/c5c856b3/attachment.html>

From aron.helser at kitware.com  Fri Jan 25 16:53:35 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Fri, 25 Jan 2019 16:53:35 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <20190123165426.GA3725@megas.kitware.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
 <20190123140503.GB30183@megas.kitware.com>
 <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>
 <20190123165426.GA3725@megas.kitware.com>
Message-ID: <CAF2skS5s5iN0DvnNvka3iKobw8K2dTN4-8c-vpAwf=rOxmcRCw@mail.gmail.com>

I reproduce this on my windows 10 desktop with VS 2017 with only

set(BUILD_SHARED_LIBS "OFF" CACHE BOOL "")
set(BUILD_TESTING "ON" CACHE BOOL "")
set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")



On Wed, Jan 23, 2019 at 11:54 AM Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Wed, Jan 23, 2019 at 10:12:18 -0500, Aron Helser wrote:
> > Hopefully the OpenVR and FFMPEG stuff aren't relevant, and can be
> omitted.
> > I'll test that.
> > I'll attach my cmakecache, too
>
> It doesn't fail on Linux here. Some debugging on Windows will be
> necessary. But, I don't have OpenVR enabled (FFMPEG is).
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190125/5ac17fbe/attachment.html>

From ben.boeckel at kitware.com  Mon Jan 28 15:55:59 2019
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 28 Jan 2019 15:55:59 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <CAF2skS5s5iN0DvnNvka3iKobw8K2dTN4-8c-vpAwf=rOxmcRCw@mail.gmail.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
 <20190123140503.GB30183@megas.kitware.com>
 <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>
 <20190123165426.GA3725@megas.kitware.com>
 <CAF2skS5s5iN0DvnNvka3iKobw8K2dTN4-8c-vpAwf=rOxmcRCw@mail.gmail.com>
Message-ID: <20190128205559.GA28637@megas.kitware.com>

On Fri, Jan 25, 2019 at 16:53:35 -0500, Aron Helser wrote:
> I reproduce this on my windows 10 desktop with VS 2017 with only
> 
> set(BUILD_SHARED_LIBS "OFF" CACHE BOOL "")
> set(BUILD_TESTING "ON" CACHE BOOL "")
> set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")

Thanks. Could you please file an issue?

--Ben

From aron.helser at kitware.com  Mon Jan 28 16:36:57 2019
From: aron.helser at kitware.com (Aron Helser)
Date: Mon, 28 Jan 2019 16:36:57 -0500
Subject: [vtk-developers] Failed OpenGL tests with vtk static windows
 build?
In-Reply-To: <20190128205559.GA28637@megas.kitware.com>
References: <CAF2skS78NbzT9KnXqao2Aa7a3tebcwDDADQnpyHKYtJD3Jnmvg@mail.gmail.com>
 <20190123140503.GB30183@megas.kitware.com>
 <CAF2skS7ek6MxmmXiVB4vNE0CZRDpkXgpqAPC+3g-w1gd+R+UAA@mail.gmail.com>
 <20190123165426.GA3725@megas.kitware.com>
 <CAF2skS5s5iN0DvnNvka3iKobw8K2dTN4-8c-vpAwf=rOxmcRCw@mail.gmail.com>
 <20190128205559.GA28637@megas.kitware.com>
Message-ID: <CAF2skS4Vv3BGaJ9OJV=YW9M0e6zCETMVov6FMZPRiXUfPMnLhw@mail.gmail.com>

Done. https://gitlab.kitware.com/vtk/vtk/issues/17510

Thanks!

On Mon, Jan 28, 2019 at 3:56 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Fri, Jan 25, 2019 at 16:53:35 -0500, Aron Helser wrote:
> > I reproduce this on my windows 10 desktop with VS 2017 with only
> >
> > set(BUILD_SHARED_LIBS "OFF" CACHE BOOL "")
> > set(BUILD_TESTING "ON" CACHE BOOL "")
> > set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")
>
> Thanks. Could you please file an issue?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190128/523bdee7/attachment.html>

From dave.demarle at kitware.com  Tue Jan 29 16:55:11 2019
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 29 Jan 2019 16:55:11 -0500
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <CANjZAi9-FKaPTdU+7sbgaWzUr38Y-8xjYHKACTP0rZFRDUNByw@mail.gmail.com>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
 <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
 <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>
 <6c547744-6d6c-fcf3-d599-3b6b157509e9@aero.iitb.ac.in>
 <CANjZAi9-FKaPTdU+7sbgaWzUr38Y-8xjYHKACTP0rZFRDUNByw@mail.gmail.com>
Message-ID: <CANjZAi85q7W6qD17La=fOhtns-Q5ydZE=hXupWo8-smaa9S0ZQ@mail.gmail.com>

So https://gitlab.kitware.com/vtk/vtk/merge_requests/5021 which makes
vtkPython optional is necessary but there is more work to be done.
We also need https://github.com/demarle/VTKPythonPackage/tree/bump-to-8.2
or something like it to put the .py's and .so's into the places that
auditwheel expects to find them.
Then we can make a wheel.

However we still need run time changes so that python and library paths
cope with the new intermediary vtkmodules directory (see
https://gitlab.kitware.com/vtk/vtk/commits/741fffb). Specifically the code
in vtk/vtk.py isn't loaded automatically like vtk/__init__.py would be and
it when I force it there are still path issues that I can thus far only
work around with hacks like extending LD_LIBRARY_PATH.

It looks doable from 8.2.0 but I'm out of time on this. So I suggest we
release 8.2.0 as it is and fix it, if required in 8.2.1. OK?

David E DeMarle
Kitware, Inc.
Principal Engineer


On Thu, Jan 3, 2019 at 11:25 AM David E DeMarle <dave.demarle at kitware.com>
wrote:

> Yes please do give it a try. Note : I am running into other issues making
> the wheels for 8.2.0. If I could get you and/or JC to take a look it would
> be great.
>
> My WIP branch:
> https://github.com/demarle/VTKPythonPackage/tree/bump-to-8.2
> Results in:
> running clean
> removing '_skbuild/linux-x86_64-3.6/cmake-install'
> removing '_skbuild/linux-x86_64-3.6/cmake-build'
> removing '_skbuild/linux-x86_64-3.6'
> + find /work/VTK-cp36-cp36m-manylinux1_x64 -name '*.o' -delete
> ++ uname -p
> + for whl in 'dist/*linux_$(uname -p).whl'
> + auditwheel repair dist/vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
> --lib-sdir . -w /work/dist/
> Repairing vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
> Traceback (most recent call last):
>   File "/usr/local/bin/auditwheel", line 11, in <module>
>     sys.exit(main())
>   File
> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main.py",
> line 49, in main
>     rval = args.func(args, p)
>   File
> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main_repair.py",
> line 77, in execute
>     update_tags=args.UPDATE_TAGS)
>   File
> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/repair.py",
> line 82, in repair_wheel
>     soname)
> ValueError: Cannot repair wheel, because required library
> "libvtkImaging-8.2.so.1" could not be located
>
> Where the specific library changes each run. On the same machine, running
> master  of VTKPyPackage (so vtk 8.1.2) works fine.
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
>
>
> On Wed, Jan 2, 2019 at 10:17 PM Prabhu Ramachandran <
> prabhu at aero.iitb.ac.in> wrote:
>
>> Sorry I dropped off the radar.  I have been traveling and my semester
>> starts today.  I can try this weekend and test it out.  Does that work?
>>
>> Regards,
>> Prabhu
>>
>> On 1/3/19 3:00 AM, Matt McCormick wrote:
>>
>> On Wed, Jan 2, 2019 at 4:13 PM David E DeMarle via vtk-developers<vtk-developers at vtk.org> <vtk-developers at vtk.org> wrote:
>>
>> I've been holding off 8.2.0.final to get a better handle on wheel building.
>>
>> Please review the potential fix in: https://gitlab.kitware.com/vtk/vtk/merge_requests/5021
>>
>> Excellent, thanks!
>>
>> This looks good to me.
>>
>>
>>
>> @Prabhu Ramachandran, @Jean-Christophe Fillion-Robin building the wheels seem to be OK off of this on my desktop. How do I locally test their validity?
>>
>> Create a virtualenv, make sure pip can recognize and install the wheel
>> from the local directory, and test it on VTK examples. For example,
>>
>>   python3 -m venv test-venv
>>   ./test-venv/bin/python -m pip install --upgrade pip
>>   ./test-venv/bin/python -m pip install numpy
>>   # dist/ contains the generated vtk-8.2.0-cp36-cp36m-manylinux1_x86_64.whl
>>   ./test-venv/bin/python -m pip install vtk --no-cache-dir --no-index -f ./dist/
>>   ./test-venv/bin/python /path/to/vtk/script.py
>>
>>
>> HTH,
>> Matt
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190129/30ed44e3/attachment.html>

From matt.mccormick at kitware.com  Tue Jan 29 17:59:37 2019
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 29 Jan 2019 17:59:37 -0500
Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels
In-Reply-To: <CANjZAi85q7W6qD17La=fOhtns-Q5ydZE=hXupWo8-smaa9S0ZQ@mail.gmail.com>
References: <d37c4b98-3649-8283-ea23-783c5053fcb0@aero.iitb.ac.in>
 <CANLz8R7du7AGbY1J1iwnYfZUmkdPGwc1ea-gNc=mGF4CxxNpfA@mail.gmail.com>
 <20181128160041.GA25730@megas.kitware.com>
 <ac497502-6b59-5676-3474-4914dfcca0c2@aero.iitb.ac.in>
 <20181128204433.GB4242@megas.kitware.com>
 <CANjZAi9R_3LTcyzQh-RnG37fV2s1LuDq9e7q4SvZr2naPoZ45A@mail.gmail.com>
 <CANjZAi-tVODk8CwBhO8DUxtnHeibqzGDuyHo=vT0Dzha6iF7fA@mail.gmail.com>
 <CALzTN-TFNnsQJ=19p=z=c+Qj0Dt+Kg_M452USu6VzueAnAUgkw@mail.gmail.com>
 <6c547744-6d6c-fcf3-d599-3b6b157509e9@aero.iitb.ac.in>
 <CANjZAi9-FKaPTdU+7sbgaWzUr38Y-8xjYHKACTP0rZFRDUNByw@mail.gmail.com>
 <CANjZAi85q7W6qD17La=fOhtns-Q5ydZE=hXupWo8-smaa9S0ZQ@mail.gmail.com>
Message-ID: <CALzTN-QvJyr0Y3irJa1DRErxH7fMpJfu8JKDFAAC764+k5=NZw@mail.gmail.com>

Sounds like a plan.

The easiest approach that faciliates cross-platform library loading in the
wheel is to place the libraries and the C-extension binaries in the same
directory, if possible.

On Tue, Jan 29, 2019 at 4:55 PM David E DeMarle <dave.demarle at kitware.com>
wrote:

> So https://gitlab.kitware.com/vtk/vtk/merge_requests/5021 which makes
> vtkPython optional is necessary but there is more work to be done.
> We also need https://github.com/demarle/VTKPythonPackage/tree/bump-to-8.2
> or something like it to put the .py's and .so's into the places that
> auditwheel expects to find them.
> Then we can make a wheel.
>
> However we still need run time changes so that python and library paths
> cope with the new intermediary vtkmodules directory (see
> https://gitlab.kitware.com/vtk/vtk/commits/741fffb). Specifically the
> code in vtk/vtk.py isn't loaded automatically like vtk/__init__.py would be
> and it when I force it there are still path issues that I can thus far only
> work around with hacks like extending LD_LIBRARY_PATH.
>
> It looks doable from 8.2.0 but I'm out of time on this. So I suggest we
> release 8.2.0 as it is and fix it, if required in 8.2.1. OK?
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
>
>
> On Thu, Jan 3, 2019 at 11:25 AM David E DeMarle <dave.demarle at kitware.com>
> wrote:
>
>> Yes please do give it a try. Note : I am running into other issues making
>> the wheels for 8.2.0. If I could get you and/or JC to take a look it would
>> be great.
>>
>> My WIP branch:
>> https://github.com/demarle/VTKPythonPackage/tree/bump-to-8.2
>> Results in:
>> running clean
>> removing '_skbuild/linux-x86_64-3.6/cmake-install'
>> removing '_skbuild/linux-x86_64-3.6/cmake-build'
>> removing '_skbuild/linux-x86_64-3.6'
>> + find /work/VTK-cp36-cp36m-manylinux1_x64 -name '*.o' -delete
>> ++ uname -p
>> + for whl in 'dist/*linux_$(uname -p).whl'
>> + auditwheel repair dist/vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
>> --lib-sdir . -w /work/dist/
>> Repairing vtk-8.2.0rc2-cp36-cp36m-linux_x86_64.whl
>> Traceback (most recent call last):
>>   File "/usr/local/bin/auditwheel", line 11, in <module>
>>     sys.exit(main())
>>   File
>> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main.py",
>> line 49, in main
>>     rval = args.func(args, p)
>>   File
>> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/main_repair.py",
>> line 77, in execute
>>     update_tags=args.UPDATE_TAGS)
>>   File
>> "/opt/_internal/cpython-3.6.7/lib/python3.6/site-packages/auditwheel/repair.py",
>> line 82, in repair_wheel
>>     soname)
>> ValueError: Cannot repair wheel, because required library
>> "libvtkImaging-8.2.so.1" could not be located
>>
>> Where the specific library changes each run. On the same machine, running
>> master  of VTKPyPackage (so vtk 8.1.2) works fine.
>>
>> David E DeMarle
>> Kitware, Inc.
>> Principal Engineer
>>
>>
>> On Wed, Jan 2, 2019 at 10:17 PM Prabhu Ramachandran <
>> prabhu at aero.iitb.ac.in> wrote:
>>
>>> Sorry I dropped off the radar.  I have been traveling and my semester
>>> starts today.  I can try this weekend and test it out.  Does that work?
>>>
>>> Regards,
>>> Prabhu
>>>
>>> On 1/3/19 3:00 AM, Matt McCormick wrote:
>>>
>>> On Wed, Jan 2, 2019 at 4:13 PM David E DeMarle via vtk-developers<vtk-developers at vtk.org> <vtk-developers at vtk.org> wrote:
>>>
>>> I've been holding off 8.2.0.final to get a better handle on wheel building.
>>>
>>> Please review the potential fix in: https://gitlab.kitware.com/vtk/vtk/merge_requests/5021
>>>
>>> Excellent, thanks!
>>>
>>> This looks good to me.
>>>
>>>
>>>
>>> @Prabhu Ramachandran, @Jean-Christophe Fillion-Robin building the wheels seem to be OK off of this on my desktop. How do I locally test their validity?
>>>
>>> Create a virtualenv, make sure pip can recognize and install the wheel
>>> from the local directory, and test it on VTK examples. For example,
>>>
>>>   python3 -m venv test-venv
>>>   ./test-venv/bin/python -m pip install --upgrade pip
>>>   ./test-venv/bin/python -m pip install numpy
>>>   # dist/ contains the generated vtk-8.2.0-cp36-cp36m-manylinux1_x86_64.whl
>>>   ./test-venv/bin/python -m pip install vtk --no-cache-dir --no-index -f ./dist/
>>>   ./test-venv/bin/python /path/to/vtk/script.py
>>>
>>>
>>> HTH,
>>> Matt
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190129/d40d8096/attachment-0001.html>

From zack.galbreath at kitware.com  Thu Jan 31 13:53:48 2019
From: zack.galbreath at kitware.com (Zack Galbreath)
Date: Thu, 31 Jan 2019 13:53:48 -0500
Subject: [vtk-developers] CDash frontend refresh
Message-ID: <CANgkMA6RUuZz0YAKreqGCD8MOnfOwWfGA2zK2nK7fUDORki=QQ@mail.gmail.com>

We've been working on a refresh of CDash's look and feel. Before rolling
this out, we wanted to give you all a sneak peek so that you could let us
know what you think.

Our proposed changes are now live on http://testing.cdash.org, which shares
a backend database with https://open.cdash.org.

For example,
old:   https://open.cdash.org/index.php?project=VTK
new: http://testing.cdash.org/index.php?project=VTK

This is inevitably a work in progress so future tweaks should be expected.
That being said, please let us know if you see anything that seems like an
obvious defect to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/9aeff56d/attachment.html>

From tj.corona at kitware.com  Thu Jan 31 15:00:47 2019
From: tj.corona at kitware.com (TJ Corona)
Date: Thu, 31 Jan 2019 15:00:47 -0500
Subject: [vtk-developers] CDash frontend refresh
In-Reply-To: <CANgkMA6RUuZz0YAKreqGCD8MOnfOwWfGA2zK2nK7fUDORki=QQ@mail.gmail.com>
References: <CANgkMA6RUuZz0YAKreqGCD8MOnfOwWfGA2zK2nK7fUDORki=QQ@mail.gmail.com>
Message-ID: <8702064F-D659-48BF-9150-6A432DD911CC@kitware.com>

Hi Zack,

I like the new layout! It?s very clean. Would it be possible to add an option to use the original table colors (green, yellow, red)? I can?t put my finger on why, but I find the new color palette more difficult to read.

Sincerely,
T.J.

> On Jan 31, 2019, at 1:53 PM, Zack Galbreath via vtk-developers <vtk-developers at vtk.org> wrote:
> 
> We've been working on a refresh of CDash's look and feel. Before rolling this out, we wanted to give you all a sneak peek so that you could let us know what you think.
> 
> Our proposed changes are now live on http://testing.cdash.org <http://testing.cdash.org/>, which shares a backend database with https://open.cdash.org <https://open.cdash.org/>.
> 
> For example,
> old:   https://open.cdash.org/index.php?project=VTK <https://open.cdash.org/index.php?project=VTK>
> new: http://testing.cdash.org/index.php?project=VTK <http://testing.cdash.org/index.php?project=VTK>
> 
> This is inevitably a work in progress so future tweaks should be expected. That being said, please let us know if you see anything that seems like an obvious defect to you.
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/16234aa5/attachment.html>

From dan.lipsa at kitware.com  Thu Jan 31 15:12:43 2019
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Thu, 31 Jan 2019 15:12:43 -0500
Subject: [vtk-developers] CDash frontend refresh
In-Reply-To: <8702064F-D659-48BF-9150-6A432DD911CC@kitware.com>
References: <CANgkMA6RUuZz0YAKreqGCD8MOnfOwWfGA2zK2nK7fUDORki=QQ@mail.gmail.com>
 <8702064F-D659-48BF-9150-6A432DD911CC@kitware.com>
Message-ID: <CADwGrVrW2_r-yrznrBgS5KrtECKuEQMr1UVK_1CO0w4Z5Y3ctQ@mail.gmail.com>

Maybe the problem is the white text?
There isn't enough difference between the fairly pale color (red, yellow)
and the text color.

Changing the text color to black might make it more readable and will make
the text that shows the number of errors (or warnings) consistent.

On Thu, Jan 31, 2019 at 3:00 PM TJ Corona via vtk-developers <
vtk-developers at vtk.org> wrote:

> Hi Zack,
>
> I like the new layout! It?s very clean. Would it be possible to add an
> option to use the original table colors (green, yellow, red)? I can?t put
> my finger on why, but I find the new color palette more difficult to read.
>
> Sincerely,
> T.J.
>
> On Jan 31, 2019, at 1:53 PM, Zack Galbreath via vtk-developers <
> vtk-developers at vtk.org> wrote:
>
> We've been working on a refresh of CDash's look and feel. Before rolling
> this out, we wanted to give you all a sneak peek so that you could let us
> know what you think.
>
> Our proposed changes are now live on http://testing.cdash.org, which
> shares a backend database with https://open.cdash.org.
>
> For example,
> old:   https://open.cdash.org/index.php?project=VTK
> new: http://testing.cdash.org/index.php?project=VTK
>
> This is inevitably a work in progress so future tweaks should be expected.
> That being said, please let us know if you see anything that seems like an
> obvious defect to you.
> _______________________________________________
> 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://vtk.org/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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/cfddc908/attachment.html>

From bill.lorensen at gmail.com  Thu Jan 31 18:14:02 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 31 Jan 2019 15:14:02 -0800
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile on
 Ubuntu 14
Message-ID: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>

I get the following error:

/home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:
In member function ?virtual int
vtkBandedPolyDataContourFilter::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)?:
/home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:832:58:
error: ?void it? has incomplete type
           auto it = std::rotate( index.begin(), r1, l1+1 );

It seems that std::rotate returning an iterator was introduced in c++11.

My gcc is:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4



-- 
Unpaid intern in BillsParadise at noware dot com

From david.thompson at kitware.com  Thu Jan 31 18:48:20 2019
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 31 Jan 2019 18:48:20 -0500
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile
 on Ubuntu 14
In-Reply-To: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>
References: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>
Message-ID: <A5799092-8C1A-4453-BD58-22F255709014@kitware.com>

Hi Bill,

That is due to this MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/5102#note_510947
which passed VTK's CI build tests. I can ping Andreas to take a look at it, but my question for the larger group is what compilers we aim to support. I know VTK now allows code that uses some C++11 language and library features but don't know if there is a list of minimum requirements anywhere.

    David  

> On Jan 31, 2019, at 18:14, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 
> I get the following error:
> 
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:
> In member function ?virtual int
> vtkBandedPolyDataContourFilter::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)?:
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:832:58:
> error: ?void it? has incomplete type
>           auto it = std::rotate( index.begin(), r1, l1+1 );
> 
> It seems that std::rotate returning an iterator was introduced in c++11.
> 
> My gcc is:
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
> 
> 
> 
> -- 
> Unpaid intern in BillsParadise at noware dot com
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/0ae1c5f7/attachment-0001.html>

From bill.lorensen at gmail.com  Thu Jan 31 20:21:28 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 31 Jan 2019 17:21:28 -0800
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile
 on Ubuntu 14
In-Reply-To: <A5799092-8C1A-4453-BD58-22F255709014@kitware.com>
References: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>
 <A5799092-8C1A-4453-BD58-22F255709014@kitware.com>
Message-ID: <CADZJ4hOMphF-jURkUJoH0cFggcGjLxvijFgTgjY3T=DB4Lqw7g@mail.gmail.com>

I sure hope we will still support Ubuntu 14. This is the only compile
error. They must be a work around.

Thankd

On Thu, Jan 31, 2019, 3:48 PM David Thompson <david.thompson at kitware.com
wrote:

> Hi Bill,
>
> That is due to this MR:
> https://gitlab.kitware.com/vtk/vtk/merge_requests/5102#note_510947
> which passed VTK's CI build tests. I can ping Andreas to take a look at
> it, but my question for the larger group is what compilers we aim to
> support. I know VTK now allows code that uses some C++11 language and
> library features but don't know if there is a list of minimum requirements
> anywhere.
>
>     David
>
> On Jan 31, 2019, at 18:14, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> I get the following error:
>
>
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:
> In member function ?virtual int
> vtkBandedPolyDataContourFilter::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)?:
>
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:832:58:
> error: ?void it? has incomplete type
>           auto it = std::rotate( index.begin(), r1, l1+1 );
>
> It seems that std::rotate returning an iterator was introduced in c++11.
>
> My gcc is:
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
>
>
>
> --
> Unpaid intern in BillsParadise at noware dot com
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/cc154fc6/attachment.html>

From david.thompson at kitware.com  Thu Jan 31 20:37:32 2019
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 31 Jan 2019 20:37:32 -0500
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile
 on Ubuntu 14
In-Reply-To: <CADZJ4hOMphF-jURkUJoH0cFggcGjLxvijFgTgjY3T=DB4Lqw7g@mail.gmail.com>
References: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>
 <A5799092-8C1A-4453-BD58-22F255709014@kitware.com>
 <CADZJ4hOMphF-jURkUJoH0cFggcGjLxvijFgTgjY3T=DB4Lqw7g@mail.gmail.com>
Message-ID: <C300AEFC-CA60-451D-BDA3-C3D0BE3FF21E@kitware.com>

Hi Bill,

> I sure hope we will still support Ubuntu 14. This is the only compile error. They must be a work around.

I'm not sure it is a good idea to support old compilers and distributions:

1. Ubuntu 14.04 LTS will lose support from Canonical in 3 months. I would be surprised if what is in git master is released by then. Why should we support platforms no longer supported by their distributor?

2. If we keep forcing workarounds, the next time something breaks, then *it* will be the only compiler error. That pattern just keeps accruing technical debt. Ultimately, I believe that technical debt will push developers away from VTK so I want to avoid it.

3. Not too long ago, it was common practice for systems in production use to never get patched (lest the patch break what was working). However, security issues and increased connectivity prevalent today has pretty much put a stop to this practice and I think that translates into a much weaker argument for supporting older systems.

	David

From andrew.amaclean at gmail.com  Thu Jan 31 21:00:27 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 1 Feb 2019 13:00:27 +1100
Subject: [vtk-developers] vtk-developers Digest, Vol 177, Issue 52
In-Reply-To: <mailman.959.1548978505.2633.vtk-developers@vtk.org>
References: <mailman.959.1548978505.2633.vtk-developers@vtk.org>
Message-ID: <CAHDsG9PL16WLaUT5=W2+TrrCx1Xq9G=iXtsZvYD4qfUXcC168Q@mail.gmail.com>

BIll, David

   That's a pretty old compiler, from memory, and I may be wrong, I think
that gcc support was largely experimental in that compiler.
So there may be issues like this, or more, arising in older compilers where
c++11 support was largely experimental or incomplete.

Andrew Maclean


>
>
> ---------- Forwarded message ----------
> From: David Thompson <david.thompson at kitware.com>
> To: Bill Lorensen <bill.lorensen at gmail.com>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Bcc:
> Date: Thu, 31 Jan 2019 18:48:20 -0500
> Subject: Re: [vtk-developers] BandedPolyDataContourFilter failes to
> compile on Ubuntu 14
> Hi Bill,
>
> That is due to this MR:
> https://gitlab.kitware.com/vtk/vtk/merge_requests/5102#note_510947
> which passed VTK's CI build tests. I can ping Andreas to take a look at
> it, but my question for the larger group is what compilers we aim to
> support. I know VTK now allows code that uses some C++11 language and
> library features but don't know if there is a list of minimum requirements
> anywhere.
>
>     David
>
> On Jan 31, 2019, at 18:14, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> I get the following error:
>
>
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:
> In member function ?virtual int
> vtkBandedPolyDataContourFilter::RequestData(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)?:
>
> /home/lorensen/ProjectsGIT/VTKNewModules/Filters/Modeling/vtkBandedPolyDataContourFilter.cxx:832:58:
> error: ?void it? has incomplete type
>           auto it = std::rotate( index.begin(), r1, l1+1 );
>
> It seems that std::rotate returning an iterator was introduced in c++11.
>
> My gcc is:
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
>
>
>
> --
> Unpaid intern in BillsParadise at noware dot com
> _______________________________________________
> 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://vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190201/60181018/attachment.html>

From bill.lorensen at gmail.com  Thu Jan 31 21:02:33 2019
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 31 Jan 2019 18:02:33 -0800
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile
 on Ubuntu 14
In-Reply-To: <C300AEFC-CA60-451D-BDA3-C3D0BE3FF21E@kitware.com>
References: <CADZJ4hNyWnc=Z43Dy39okCYGKo7cF3hAhR1Eqz4aNEZQhbywrQ@mail.gmail.com>
 <A5799092-8C1A-4453-BD58-22F255709014@kitware.com>
 <CADZJ4hOMphF-jURkUJoH0cFggcGjLxvijFgTgjY3T=DB4Lqw7g@mail.gmail.com>
 <C300AEFC-CA60-451D-BDA3-C3D0BE3FF21E@kitware.com>
Message-ID: <CADZJ4hMXwyw7i1uKW7vnUuw4fsCcDQVqtV8sFSqqc5F-CVgz0g@mail.gmail.com>

I'm talking about 1 compile error that can be worked around. I have an mr
I'll push tomorrow.

On Thu, Jan 31, 2019, 5:38 PM David Thompson <david.thompson at kitware.com
wrote:

> Hi Bill,
>
> > I sure hope we will still support Ubuntu 14. This is the only compile
> error. They must be a work around.
>
> I'm not sure it is a good idea to support old compilers and distributions:
>
> 1. Ubuntu 14.04 LTS will lose support from Canonical in 3 months. I would
> be surprised if what is in git master is released by then. Why should we
> support platforms no longer supported by their distributor?
>
> 2. If we keep forcing workarounds, the next time something breaks, then
> *it* will be the only compiler error. That pattern just keeps accruing
> technical debt. Ultimately, I believe that technical debt will push
> developers away from VTK so I want to avoid it.
>
> 3. Not too long ago, it was common practice for systems in production use
> to never get patched (lest the patch break what was working). However,
> security issues and increased connectivity prevalent today has pretty much
> put a stop to this practice and I think that translates into a much weaker
> argument for supporting older systems.
>
>         David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190131/1beed9db/attachment-0001.html>

From andrew.amaclean at gmail.com  Thu Jan 31 21:14:31 2019
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 1 Feb 2019 13:14:31 +1100
Subject: [vtk-developers] BandedPolyDataContourFilter failes to compile
 on Ubuntu 14
In-Reply-To: <mailman.963.1548986567.2633.vtk-developers@vtk.org>
References: <mailman.963.1548986567.2633.vtk-developers@vtk.org>
Message-ID: <CAHDsG9PWp+Vhfim7aaHqqAa5Q79teDaDn7jy6_Q5VhF3NbrSCA@mail.gmail.com>

David, Bill

I agree with you on this David. Especially in relation to point 3.

In relation to point 2 there is an additional  problem with work arounds in
that they may also significantly affect performance.

There is no point in supporting Ubunto 14 if support is being dropped in
three months.


Regards
   Andrew


> ---------- Forwarded message ----------
> From: David Thompson <david.thompson at kitware.com>
> To: Bill Lorensen <bill.lorensen at gmail.com>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Bcc:
> Date: Thu, 31 Jan 2019 20:37:32 -0500
> Subject: Re: [vtk-developers] BandedPolyDataContourFilter failes to
> compile on Ubuntu 14
> Hi Bill,
>
> > I sure hope we will still support Ubuntu 14. This is the only compile
> error. They must be a work around.
>
> I'm not sure it is a good idea to support old compilers and distributions:
>
> 1. Ubuntu 14.04 LTS will lose support from Canonical in 3 months. I would
> be surprised if what is in git master is released by then. Why should we
> support platforms no longer supported by their distributor?
>
> 2. If we keep forcing workarounds, the next time something breaks, then
> *it* will be the only compiler error. That pattern just keeps accruing
> technical debt. Ultimately, I believe that technical debt will push
> developers away from VTK so I want to avoid it.
>
> 3. Not too long ago, it was common practice for systems in production use
> to never get patched (lest the patch break what was working). However,
> security issues and increased connectivity prevalent today has pretty much
> put a stop to this practice and I think that translates into a much weaker
> argument for supporting older systems.
>
>         David
>
>
>
> --
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190201/120dca47/attachment.html>