From sean at rogue-research.com Mon Dec 1 14:29:38 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 1 Dec 2014 14:29:38 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... Message-ID: <20141201192938.1494312997@mail.rogue-research.com> Hi all, I've just now rebuilt & installed VTK master, and it seems there is a regression with HDF5-related install files. If building Release, I get what I expect, which is two files named: libvtkhdf5_hl.a libvtkhdf5.a in the /lib install folder. But building debug, I get instead: libvtkhdf5_debug.a libvtkhdf5_hl_debug.a This was not the case previously, and seems incorrect. Anyone know about this breakage, and can hopefully fix it? :) 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 robert.maynard at kitware.com Mon Dec 1 14:39:01 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 1 Dec 2014 14:39:01 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: <20141201192938.1494312997@mail.rogue-research.com> References: <20141201192938.1494312997@mail.rogue-research.com> Message-ID: I expect that this was caused by the upgrade to hdf5 1.8. This shouldn't be super hard to fix, as the library naming logic is all in ThirdParty/hdf5/vtkhdf5/config/cmake/HDFLibMacros.cmake On Mon, Dec 1, 2014 at 2:29 PM, Sean McBride wrote: > Hi all, > > I've just now rebuilt & installed VTK master, and it seems there is a regression with HDF5-related install files. > > If building Release, I get what I expect, which is two files named: > > libvtkhdf5_hl.a > libvtkhdf5.a > > in the /lib install folder. But building debug, I get instead: > > libvtkhdf5_debug.a > libvtkhdf5_hl_debug.a > > This was not the case previously, and seems incorrect. > > Anyone know about this breakage, and can hopefully fix it? :) > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From sean at rogue-research.com Mon Dec 1 15:53:13 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 1 Dec 2014 15:53:13 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: References: <20141201192938.1494312997@mail.rogue-research.com> Message-ID: <20141201205313.108332041@mail.rogue-research.com> Robert, Thanks for your reply. I guess you mean this: --------------- commit c76a183cb4bdfd255c60b006d84f82a259cd6de6 Merge: f0480df db8d3e2 Author: Dan Lipsa Date: Sun Nov 23 16:49:15 2014 -0500 Merge topic 'update-hdf5' into master --------------- I'm trying the commit before it to verify. Also, I retract my statement that in Release I get what I expect, even there the name is wrong, it's missing the "-6.2" at the end (that every other library file has). If I rename them manually, I hit another problem, a link error: duplicate symbol _H5MM_malloc duplicate symbol _H5MM_calloc My app links to another HDF5, and so I presume those two functions are not being mangled in vtk_libhdf5_mangle.h. Sean On Mon, 1 Dec 2014 14:39:01 -0500, Robert Maynard said: >I expect that this was caused by the upgrade to hdf5 1.8. This >shouldn't be super hard to fix, as the library naming logic is all in >ThirdParty/hdf5/vtkhdf5/config/cmake/HDFLibMacros.cmake > >On Mon, Dec 1, 2014 at 2:29 PM, Sean McBride wrote: >> Hi all, >> >> I've just now rebuilt & installed VTK master, and it seems there is a >regression with HDF5-related install files. >> >> If building Release, I get what I expect, which is two files named: >> >> libvtkhdf5_hl.a >> libvtkhdf5.a >> >> in the /lib install folder. But building debug, I get instead: >> >> libvtkhdf5_debug.a >> libvtkhdf5_hl_debug.a >> >> This was not the case previously, and seems incorrect. >> >> Anyone know about this breakage, and can hopefully fix it? :) >> >> Thanks, From bill.lorensen at gmail.com Tue Dec 2 11:04:44 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 2 Dec 2014 11:04:44 -0500 Subject: [vtk-developers] Missing "Infovis" classes Message-ID: Folks, A user just reported that vtkConvexHull2D was not being compiled. After further investigation,, I see that the following classes are in the Infovis/Core directory, but are not being compiled: vtkConvexHull2D vtkDotProductSimilarity vtkGraphAnnotationLayersFilter vtkTransferAttributes Looks to me that vtkConvexHull2D and vtkGraphAnnotationLayersFilter should be moved into Rendering/Annotation. I'll be happy to work on a patch. Bill From dan.lipsa at kitware.com Tue Dec 2 11:37:50 2014 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 2 Dec 2014 11:37:50 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> Message-ID: Hi Sean, I pushed a fix for these issues to VTK master. Thanks again for your report. Dan On Mon, Dec 1, 2014 at 4:07 PM, Dan Lipsa wrote: > Hi Sean, > Thanks for your report. I am looking at this right now. > > Dan > > > On Mon, Dec 1, 2014 at 3:53 PM, Sean McBride > wrote: > >> Robert, >> >> Thanks for your reply. I guess you mean this: >> >> --------------- >> commit c76a183cb4bdfd255c60b006d84f82a259cd6de6 >> Merge: f0480df db8d3e2 >> Author: Dan Lipsa >> Date: Sun Nov 23 16:49:15 2014 -0500 >> >> Merge topic 'update-hdf5' into master >> --------------- >> >> I'm trying the commit before it to verify. >> >> Also, I retract my statement that in Release I get what I expect, even >> there the name is wrong, it's missing the "-6.2" at the end (that every >> other library file has). >> >> If I rename them manually, I hit another problem, a link error: >> >> duplicate symbol _H5MM_malloc >> duplicate symbol _H5MM_calloc >> >> My app links to another HDF5, and so I presume those two functions are >> not being mangled in vtk_libhdf5_mangle.h. >> >> Sean >> >> >> >> On Mon, 1 Dec 2014 14:39:01 -0500, Robert Maynard said: >> >> >I expect that this was caused by the upgrade to hdf5 1.8. This >> >shouldn't be super hard to fix, as the library naming logic is all in >> >ThirdParty/hdf5/vtkhdf5/config/cmake/HDFLibMacros.cmake >> > >> >On Mon, Dec 1, 2014 at 2:29 PM, Sean McBride >> wrote: >> >> Hi all, >> >> >> >> I've just now rebuilt & installed VTK master, and it seems there is a >> >regression with HDF5-related install files. >> >> >> >> If building Release, I get what I expect, which is two files named: >> >> >> >> libvtkhdf5_hl.a >> >> libvtkhdf5.a >> >> >> >> in the /lib install folder. But building debug, I get instead: >> >> >> >> libvtkhdf5_debug.a >> >> libvtkhdf5_hl_debug.a >> >> >> >> This was not the case previously, and seems incorrect. >> >> >> >> Anyone know about this breakage, and can hopefully fix it? :) >> >> >> >> Thanks, >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Dec 2 11:45:27 2014 From: sean at rogue-research.com (Sean McBride) Date: Tue, 2 Dec 2014 11:45:27 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> Message-ID: <20141202164527.1237849103@mail.rogue-research.com> On Tue, 2 Dec 2014 11:37:50 -0500, Dan Lipsa said: >I pushed a fix for these issues to VTK master. Dan, Thanks for the quick work! I was just testing the changes. It's much better now but there's one issue left... the filenames I get, in both debug and release are now: libvtkhdf5_hl.a libvtkhdf5.a but every other library file is named with "-6.2" in the file name, like, to take 3 examples: libvtkCommonCore-6.2.a libvtkexpat-6.2.a libvtkNetCDF-6.2.a The HDF files used to have this version number too. 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 david.gobbi at gmail.com Tue Dec 2 11:46:36 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 2 Dec 2014 09:46:36 -0700 Subject: [vtk-developers] Wrapping enum types In-Reply-To: References: Message-ID: Still waiting for reviewers for http://review.source.kitware.com/#/c/17993 (refactoring the python wrappers and wrapping enum types). Big thanks to Ben for his comments so far. - David On Fri, Nov 21, 2014 at 10:58 AM, David Gobbi wrote: > Hi All, > > The enum support for the wrappers is done (pending merge). The caveat > that I mentioned in my previous email no longer applies, i.e. with this new > patch _all_ enum types are wrapped, whether they are in the global > namespace, in a class namespace, or in any other namespace (except for > nested namespaces, which aren't supported by the wrappers yet). > > This change isn't going to have much impact on the VTK core, because > most VTK class methods simply take "int" parameters instead of requiring > the use of enums. However, it will have a _big_ impact for the wrapping > of third-party VTK classes which tend to use enum parameters quite often. > (In fact the change was motivated by the need to wrap some of my own > external classes). > > Enum parameter support is only provided for the python wrappers, not for > Java or Tcl. > > - David > > > On Mon, Nov 17, 2014 at 7:04 AM, David Gobbi > wrote: > >> Hi All, >> >> I have a patch in gerrit that modifies the python wrappers so that enum >> types are wrapped. This means that method parameters can be enum >> types, something that wasn't possible for wrapped methods before. >> http://review.source.kitware.com/#/c/17993 >> >> E.g.: >> >> class vtkSomeObject >> { >> public: >> enum ColorEnum { Red, Blue }; >> void SetColor(enum ColorEnum); >> }; >> >> Each enum type is wrapped as a unique python type subclassed from >> python's "int" type. So an enum can be used wherever an int can be >> used, but methods that take an enum will raise a TypeError unless >> given a value of the correct enum type. >> >> One caveat is that this only works if the method and the enum type are >> members of the same class. Sometime later I'll generalize it so that a >> method can use an enum defined in a different class, but method & enum >> in the same class seems to be the most common use case. >> >> Cheers, >> >> - David >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Tue Dec 2 12:15:29 2014 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 2 Dec 2014 12:15:29 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: <20141202164527.1237849103@mail.rogue-research.com> References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> <20141202164527.1237849103@mail.rogue-research.com> Message-ID: That is strange. My fix includes the postfix for the library name. Do you have commit 8ce63bdcaf8215c062b5acb121af65e49366d711 in your version of VTK? Somehow VTK_CUSTOM_LIBRARY_SUFFIX does not get set? I'll try with a fresh VTK from master. Dan On Tue, Dec 2, 2014 at 11:45 AM, Sean McBride wrote: > On Tue, 2 Dec 2014 11:37:50 -0500, Dan Lipsa said: > > >I pushed a fix for these issues to VTK master. > > Dan, > > Thanks for the quick work! I was just testing the changes. It's much > better now but there's one issue left... the filenames I get, in both debug > and release are now: > > libvtkhdf5_hl.a > libvtkhdf5.a > > but every other library file is named with "-6.2" in the file name, like, > to take 3 examples: > > libvtkCommonCore-6.2.a > libvtkexpat-6.2.a > libvtkNetCDF-6.2.a > > The HDF files used to have this version number too. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Tue Dec 2 14:56:48 2014 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 2 Dec 2014 14:56:48 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> <20141202164527.1237849103@mail.rogue-research.com> Message-ID: Hi Sean, Setting VTK_CUSTOM_LIBRARY_SUFFIX was fine for ParaView but not for VTK. I pushed a new change into VTK. Let me know if this fixes it. Dan On Tue, Dec 2, 2014 at 12:15 PM, Dan Lipsa wrote: > That is strange. My fix includes the postfix for the library name. Do you > have commit > 8ce63bdcaf8215c062b5acb121af65e49366d711 in your version of VTK? > > Somehow VTK_CUSTOM_LIBRARY_SUFFIX does not get set? I'll try with a fresh > VTK from master. > > Dan > > > > > > > On Tue, Dec 2, 2014 at 11:45 AM, Sean McBride > wrote: > >> On Tue, 2 Dec 2014 11:37:50 -0500, Dan Lipsa said: >> >> >I pushed a fix for these issues to VTK master. >> >> Dan, >> >> Thanks for the quick work! I was just testing the changes. It's much >> better now but there's one issue left... the filenames I get, in both debug >> and release are now: >> >> libvtkhdf5_hl.a >> libvtkhdf5.a >> >> but every other library file is named with "-6.2" in the file name, like, >> to take 3 examples: >> >> libvtkCommonCore-6.2.a >> libvtkexpat-6.2.a >> libvtkNetCDF-6.2.a >> >> The HDF files used to have this version number too. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Dec 2 16:36:36 2014 From: sean at rogue-research.com (Sean McBride) Date: Tue, 2 Dec 2014 16:36:36 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> <20141202164527.1237849103@mail.rogue-research.com> Message-ID: <20141202213636.1673346206@mail.rogue-research.com> On Tue, 2 Dec 2014 14:56:48 -0500, Dan Lipsa said: >Hi Sean, >Setting VTK_CUSTOM_LIBRARY_SUFFIX was fine for ParaView but not for VTK. I >pushed a new change into VTK. >Let me know if this fixes it. That fixed everything. Thanks! Aside: so if I set VTK_CUSTOM_LIBRARY_SUFFIX to an empty string I can get rid of the annoying version numbers in all the library names? That would be great. I don't see it in ccmake though... 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 dan.lipsa at kitware.com Tue Dec 2 16:52:54 2014 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 2 Dec 2014 16:52:54 -0500 Subject: [vtk-developers] recent HDF5-related regression with installed file names... In-Reply-To: <20141202213636.1673346206@mail.rogue-research.com> References: <20141201192938.1494312997@mail.rogue-research.com> <20141201205313.108332041@mail.rogue-research.com> <20141202164527.1237849103@mail.rogue-research.com> <20141202213636.1673346206@mail.rogue-research.com> Message-ID: > > > That fixed everything. Thanks! > Great! > > Aside: so if I set VTK_CUSTOM_LIBRARY_SUFFIX to an empty string I can get > rid of the annoying version numbers in all the library names? That would > be great. I don't see it in ccmake though... > > This is what ParaView does to use different names for those VTK libraries. They are postfixed with pv4.2 instead of 6.2. I think you could just add the variable to CMakeCache.txt. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Dec 2 23:01:07 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 2 Dec 2014 23:01:07 -0500 Subject: [vtk-developers] Wrapping enum types In-Reply-To: References: Message-ID: Hi David, I will try to take a look soon, travel and proposals have taken up more of my time than I might like. I am really pleased to see this added to the Python wrapping (although in truth would love to see it in Java/Tcl so we could actually use it in our API). Marcus On Tue, Dec 2, 2014 at 11:46 AM, David Gobbi wrote: > Still waiting for reviewers for http://review.source.kitware.com/#/c/17993 > (refactoring the python wrappers and wrapping enum types). Big thanks > to Ben for his comments so far. > > - David > > > On Fri, Nov 21, 2014 at 10:58 AM, David Gobbi wrote: >> >> Hi All, >> >> The enum support for the wrappers is done (pending merge). The caveat >> that I mentioned in my previous email no longer applies, i.e. with this >> new >> patch _all_ enum types are wrapped, whether they are in the global >> namespace, in a class namespace, or in any other namespace (except for >> nested namespaces, which aren't supported by the wrappers yet). >> >> This change isn't going to have much impact on the VTK core, because >> most VTK class methods simply take "int" parameters instead of requiring >> the use of enums. However, it will have a _big_ impact for the wrapping >> of third-party VTK classes which tend to use enum parameters quite often. >> (In fact the change was motivated by the need to wrap some of my own >> external classes). >> >> Enum parameter support is only provided for the python wrappers, not for >> Java or Tcl. >> >> - David >> >> >> On Mon, Nov 17, 2014 at 7:04 AM, David Gobbi >> wrote: >>> >>> Hi All, >>> >>> I have a patch in gerrit that modifies the python wrappers so that enum >>> types are wrapped. This means that method parameters can be enum >>> types, something that wasn't possible for wrapped methods before. >>> http://review.source.kitware.com/#/c/17993 >>> >>> E.g.: >>> >>> class vtkSomeObject >>> { >>> public: >>> enum ColorEnum { Red, Blue }; >>> void SetColor(enum ColorEnum); >>> }; >>> >>> Each enum type is wrapped as a unique python type subclassed from >>> python's "int" type. So an enum can be used wherever an int can be >>> used, but methods that take an enum will raise a TypeError unless >>> given a value of the correct enum type. >>> >>> One caveat is that this only works if the method and the enum type are >>> members of the same class. Sometime later I'll generalize it so that a >>> method can use an enum defined in a different class, but method & enum >>> in the same class seems to be the most common use case. >>> >>> Cheers, >>> >>> - David >> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Tue Dec 2 23:17:52 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 2 Dec 2014 21:17:52 -0700 Subject: [vtk-developers] Wrapping enum types In-Reply-To: References: Message-ID: Thanks, Marcus. I've been thinking about Java and Tcl, and I might implement enums in those wrappers via a simple type cast. For example, void SetColorMode(ColorModeEnum val); would be called from the Tcl and Java wrappers like this SetColorMode(static_cast(val)); with no type checking. It would be much easier to implement than making each enum into a first-class type like I've done for the Python wrappers. - David On Tue, Dec 2, 2014 at 9:01 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > Hi David, > > I will try to take a look soon, travel and proposals have taken up > more of my time than I might like. I am really pleased to see this > added to the Python wrapping (although in truth would love to see it > in Java/Tcl so we could actually use it in our API). > > Marcus > > On Tue, Dec 2, 2014 at 11:46 AM, David Gobbi > wrote: > > Still waiting for reviewers for > http://review.source.kitware.com/#/c/17993 > > (refactoring the python wrappers and wrapping enum types). Big thanks > > to Ben for his comments so far. > > > > - David > > > > > > On Fri, Nov 21, 2014 at 10:58 AM, David Gobbi > wrote: > >> > >> Hi All, > >> > >> The enum support for the wrappers is done (pending merge). The caveat > >> that I mentioned in my previous email no longer applies, i.e. with this > >> new > >> patch _all_ enum types are wrapped, whether they are in the global > >> namespace, in a class namespace, or in any other namespace (except for > >> nested namespaces, which aren't supported by the wrappers yet). > >> > >> This change isn't going to have much impact on the VTK core, because > >> most VTK class methods simply take "int" parameters instead of requiring > >> the use of enums. However, it will have a _big_ impact for the wrapping > >> of third-party VTK classes which tend to use enum parameters quite > often. > >> (In fact the change was motivated by the need to wrap some of my own > >> external classes). > >> > >> Enum parameter support is only provided for the python wrappers, not for > >> Java or Tcl. > >> > >> - David > >> > >> > >> On Mon, Nov 17, 2014 at 7:04 AM, David Gobbi > >> wrote: > >>> > >>> Hi All, > >>> > >>> I have a patch in gerrit that modifies the python wrappers so that enum > >>> types are wrapped. This means that method parameters can be enum > >>> types, something that wasn't possible for wrapped methods before. > >>> http://review.source.kitware.com/#/c/17993 > >>> > >>> E.g.: > >>> > >>> class vtkSomeObject > >>> { > >>> public: > >>> enum ColorEnum { Red, Blue }; > >>> void SetColor(enum ColorEnum); > >>> }; > >>> > >>> Each enum type is wrapped as a unique python type subclassed from > >>> python's "int" type. So an enum can be used wherever an int can be > >>> used, but methods that take an enum will raise a TypeError unless > >>> given a value of the correct enum type. > >>> > >>> One caveat is that this only works if the method and the enum type are > >>> members of the same class. Sometime later I'll generalize it so that a > >>> method can use an enum defined in a different class, but method & enum > >>> in the same class seems to be the most common use case. > >>> > >>> Cheers, > >>> > >>> - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serhattural12 at gmail.com Wed Dec 3 07:35:12 2014 From: serhattural12 at gmail.com (serseri) Date: Wed, 3 Dec 2014 05:35:12 -0700 (MST) Subject: [vtk-developers] Activiz Error Attempted to read or write protected memory Message-ID: <1417610112875-5729647.post@n5.nabble.com> Hi I have a codeblock as below and getting very strange errors: //------------------------------------------------------------------------------------- var vtkImg = vtkImageData.New(); vtkImg.SetDimensions(10, 10 , 1); vtkImg.SetNumberOfScalarComponents(1); vtkImg.SetScalarTypeToLong(); int[] dims = vtkImg.GetDimensions(); unsafe { for (int y = 0; y < dims[1]; y++) { for (int x = 0; x < dims[0]; x++) { long* pixel = (long*)vtkImg.GetScalarPointer(x, y, 0).ToPointer(); pixel[0] = 0L; } } } vtkXMLImageDataWriter writer = vtkXMLImageDataWriter.New(); writer.SetFileName("x.vti"); writer.SetInputConnection(vtkImg.GetProducerPort()); writer.Write(); //------------------------------------------------------------------------------------- It gives error like: - Unable to load DLL 'Kitware.VTK.vtkIO.Unmanaged.dll' - Attempted to read or write protected memory. This is often an indication that other memory is corrupt. If I increce z extent size like vtkImg.SetDimensions(10, 10 , 2) it runs :) If I use int type it runs. vtkImg.SetScalarTypeToInt(); I think there is some bugs. I need help. Thanks. -- View this message in context: http://vtk.1045678.n5.nabble.com/Activiz-Error-Attempted-to-read-or-write-protected-memory-tp5729647.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Wed Dec 3 10:15:02 2014 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 3 Dec 2014 10:15:02 -0500 Subject: [vtk-developers] OpenGL2 Updates Message-ID: Hello folks, I just wanted to provide some updates on what has been happening on the polygonal side of the OpenGL2 backend. First a quick clarification on naming. OpenGL2 is just a placeholder and hopefully at some point (years away?) we will remove the old OpenGL directory and rename this to just OpenGL. The 2 does not mean it is specific to OpenGL 2.0 as the backend is being designed to work with 2.1, 3.2, ES 2.0, ES 3.0, etc in the long run. Timings reported are for first frame and then subsequent frames. The following updates are a bit terse but I wanted to get something out. If you have questions on some of them just let me know and I?ll try to go into more details. Thanks Ken 1) Fixed a number of depth peeling issues. It is passing on the systems we are currently testing OpenGL2 on. 2) Spent a lot of time working on cleaning up the dashboard. We are now down to around 10 failures out of 1800 tests on most systems. On my development system it is down to 4 failures two of which I think need new valid images for valid reasons, one is a lighting issue I know about and just need to decide how to handle, and the last is just odd. 3) Implemented faster molecular rendering, the new code uses imposters and is about 5000 times faster than the old OpenGL1 code. *PDB ball stick 3CC2 atom (99K atoms plus 198K bonds)* NVidia Windows Laptop OpenGL 31.5 29.0 OpenGL2G 2.65 1.25 (using just new Glyph3D mapper 23x faster) OpenGL2 1.33 0.0057 (default use of imposters 5088x total) Intel Windows Laptop OpenGL 26.1 24.5 OpenGL2 0.422 0.0129 4) Reworked a lot of the lighting code in OpenGL2. Switched to the Blinn-Phong lighting model as that matches the old pipeline and is a tad faster. 5) Surfaces with Edges were quite slow in OpenGL2, reworked that to be much faster. 6) Worked with Tim Thirion to add OpenGL ES 3.0 support for VTK. We will need to at some point try turning on the volume rendering code and see if that works on iOS. The OpenGLES testing is very limited modules. 7) Added support (and a test) for point picking in VTK and fixed up a lingering issue with cell picking. 8) Turned on MPI and parallel for my build and resolved some issues related to those. 9) Thanks to Sandia/Bob O/Juda vtkCompositePolyDataMapper2 has been converted to the OpenGL2 backend and the performance looks really good. As this class had no tests in VTK I added a test for it. *TestCompositePolyDataMapper2* 1x64x256 (8192 cylinders/datasets 64x128 as 50% are off) Res 18 cylinders (~ 80 triangles/cyl) OpenGL 0.369 0.043 OpenGL2 0.158 0.033 Reactor (a bunch o? something no culler) OpenGL 3.18 0.554 OpenGL2 0.08 0.020 10) The RenderPasses were converted over to OpenGL2, including Gaussian, Sobel, and DepthPeeling. This enabled us to clean up the depth peeling code in Renderer to just delegate it to the renderpass; a much cleaner solution. We still have ShadowMap/Baker passes to convert. We also created a new RenderStepsPass class to make using RenderPasses easier as the old approach involved quite a bit of gluing together the steps. Converted the GuassianBlur test to use this new class. 11) RenderingParallel and MPI has been converted to work with OpenGL2. It compiles and passes a number of tests but I believe there are probably issues lurking in there to deal with that ParaView will hit. 12) Added in support for up to 6 clipping planes in the 3D mapper which fixed a couple failing tests. 13) VTK is building with iOS and has a working multitouch example. Also setup iOS dashboards for ES 2.0 and ES 3.0 to verify that iOS is at least building. 14) Marcus worked through a number of build issues to get Paraview built with the new backend. Lots of various issues with missing classes or module changes etc but it is getting there. He also worked on mesa issues with the new back end. 15) added backface property support, edge flag support, fixed a few resource leaks 16) addressing VTK?s glyphing performance. Bob O had a nice test case he made for Nuclear Energy that used multiple glyph sources and lots of glyphs (135K to 1.5 million glyphs). We were able to update the glyph mapper to be about 20 times faster than the old OpenGL. What was rendering at 1 frame a second is now very interactive. Tested on Windows/Mac/Intel/NVidia/ATI. This is done using OpenGL instanced rendering. 17) Android has both a Native and Java example working. We need to get a dashboard setup in the future to at least make sure it continues to compile. Once we have that we will probably try to extend it to at least have a burn test run etc. Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) 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: From will.schroeder at kitware.com Wed Dec 3 10:38:21 2014 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 3 Dec 2014 10:38:21 -0500 Subject: [vtk-developers] OpenGL2 Updates In-Reply-To: References: Message-ID: And a Happy Holiday to you too! What a great present, just awesome.... I've made sure that our PM and supporters at the NIH see this report, they will be pleased. W On Wed, Dec 3, 2014 at 10:15 AM, Ken Martin wrote: > Hello folks, > > > > I just wanted to provide some updates on what has been happening on the > polygonal side of the OpenGL2 backend. First a quick clarification on > naming. OpenGL2 is just a placeholder and hopefully at some point (years > away?) we will remove the old OpenGL directory and rename this to just > OpenGL. The 2 does not mean it is specific to OpenGL 2.0 as the backend is > being designed to work with 2.1, 3.2, ES 2.0, ES 3.0, etc in the long run. > Timings reported are for first frame and then subsequent frames. The > following updates are a bit terse but I wanted to get something out. If you > have questions on some of them just let me know and I?ll try to go into > more details. > > > > Thanks > > Ken > > > > 1) Fixed a number of depth peeling issues. It is passing on the > systems we are currently testing OpenGL2 on. > > > > 2) Spent a lot of time working on cleaning up the dashboard. We are > now down to around 10 failures out of 1800 tests on most systems. On my > development system it is down to 4 failures two of which I think need new > valid images for valid reasons, one is a lighting issue I know about and > just need to decide how to handle, and the last is just odd. > > > > 3) Implemented faster molecular rendering, the new code uses > imposters and is about 5000 times faster than the old OpenGL1 code. > > > > *PDB ball stick 3CC2 atom (99K atoms plus 198K bonds)* > > > > NVidia Windows Laptop > > OpenGL 31.5 29.0 > > OpenGL2G 2.65 1.25 (using just new Glyph3D mapper 23x > faster) > > OpenGL2 1.33 0.0057 (default use of imposters 5088x > total) > > > Intel Windows Laptop > > OpenGL 26.1 24.5 > > OpenGL2 0.422 0.0129 > > > > 4) Reworked a lot of the lighting code in OpenGL2. Switched to the > Blinn-Phong lighting model as that matches the old pipeline and is a tad > faster. > > > > 5) Surfaces with Edges were quite slow in OpenGL2, reworked that to > be much faster. > > > > 6) Worked with Tim Thirion to add OpenGL ES 3.0 support for VTK. We > will need to at some point try turning on the volume rendering code and see > if that works on iOS. The OpenGLES testing is very limited modules. > > > > 7) Added support (and a test) for point picking in VTK and fixed up > a lingering issue with cell picking. > > > > 8) Turned on MPI and parallel for my build and resolved some issues > related to those. > > > > 9) Thanks to Sandia/Bob O/Juda vtkCompositePolyDataMapper2 has been > converted to the OpenGL2 backend and the performance looks really good. As > this class had no tests in VTK I added a test for it. > > *TestCompositePolyDataMapper2* > > 1x64x256 (8192 cylinders/datasets 64x128 as 50% are off) > > > > Res 18 cylinders (~ 80 triangles/cyl) > > OpenGL 0.369 0.043 > > OpenGL2 0.158 0.033 > > > > Reactor (a bunch o? something no culler) > > OpenGL 3.18 0.554 > > OpenGL2 0.08 0.020 > > > > 10) The RenderPasses were converted over to OpenGL2, including > Gaussian, Sobel, and DepthPeeling. This enabled us to clean up the depth > peeling code in Renderer to just delegate it to the renderpass; a much > cleaner solution. We still have ShadowMap/Baker passes to convert. We also > created a new RenderStepsPass class to make using RenderPasses easier as > the old approach involved quite a bit of gluing together the steps. > Converted the GuassianBlur test to use this new class. > > > > 11) RenderingParallel and MPI has been converted to work with OpenGL2. > It compiles and passes a number of tests but I believe there are probably > issues lurking in there to deal with that ParaView will hit. > > > > 12) Added in support for up to 6 clipping planes in the 3D mapper which > fixed a couple failing tests. > > > > 13) VTK is building with iOS and has a working multitouch example. Also > setup iOS dashboards for ES 2.0 and ES 3.0 to verify that iOS is at least > building. > > > > 14) Marcus worked through a number of build issues to get Paraview > built with the new backend. Lots of various issues with missing classes or > module changes etc but it is getting there. He also worked on mesa issues > with the new back end. > > > > 15) added backface property support, edge flag support, fixed a few > resource leaks > > > > 16) addressing VTK?s glyphing performance. Bob O had a nice test case > he made for Nuclear Energy that used multiple glyph sources and lots of > glyphs (135K to 1.5 million glyphs). We were able to update the glyph > mapper to be about 20 times faster than the old OpenGL. What was rendering > at 1 frame a second is now very interactive. Tested on > Windows/Mac/Intel/NVidia/ATI. This is done using OpenGL instanced rendering. > > > > 17) Android has both a Native and Java example working. We need to get > a dashboard setup in the future to at least make sure it continues to > compile. Once we have that we will probably try to extend it to at least > have a burn test run etc. > > > > > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > ken.martin at kitware.com > > 518 881-4901 (w) > > 518 371-4573 (f) > > > > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- William J. Schroeder, PhD Kitware, Inc. 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: From sean at rogue-research.com Wed Dec 3 12:08:06 2014 From: sean at rogue-research.com (Sean McBride) Date: Wed, 3 Dec 2014 12:08:06 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: References: <20141121164611.1400065013@mail.rogue-research.com> Message-ID: <20141203170806.1684765413@mail.rogue-research.com> Thanks David for fixing #2, and thanks Dan Lipsa for doing #3. Anyone know vtkPolyLine.cxx to look at #1? And to add a #4: Common/ExecutionModel/vtkCompositeDataPipeline.cxx:1047:5: Value stored to 'outputPort' is never read The whole block of code seems pointless because nothing actually uses 'outputPort' after setting it. // Save the information about COMPOSITE_INDICES() as needed in the data // object. int outputPort = 0; if(request->Has(FROM_OUTPUT_PORT())) { outputPort = request->Get(FROM_OUTPUT_PORT()); outputPort = (outputPort >= 0 ? outputPort : 0); } Thanks, Sean On Fri, 21 Nov 2014 10:20:54 -0700, David Gobbi said: >Hi Sean, > >I can fix vtkCellPicker.cxx by making the code able to handle the >case that property is null. > > - David > > >On Fri, Nov 21, 2014 at 9:46 AM, Sean McBride >wrote: > >> Hi all, >> >> Occasionally, I try to fix some of the hundreds of clang static analyzer >> warnings in VTK. Some are easy, some are false positives, and some are >> real problems that I don't know how to fix. I'd like to appeal to you all >> to help fix these 3: >> >> 1) >> file: Common/DataModel/vtkPolyLine.cxx >> method: vtkPolyLine::GenerateSlidingNormals >> lines: 227-237 >> problem: dead code. The "if ( largeRotation )" branch sets "theta" then >> nothing uses it. >> >> 2) >> file: Rendering/Core/vtkCellPicker.cxx >> method: vtkCellPicker::IntersectVolumeWithLine >> line: 691 >> problem: the 'property' pointer is initialized to null, and if the >> subsequent 'if' is not entered, it's certainly still null at line 691 and >> dereferenced. >> >> 3) >> file: Common/DataModel/vtkKdTree.cxx >> line: 3188 >> method: vtkKdTree::GenerateRepresentationWholeSpace >> problem: the first time through the 'for' loop always does "1 << -1". You >> can't left shift by a negative count. >> >> I don't want to blindly delete dead code that maybe shouldn't be dead, or >> just throw in null checks, so hopefully someone knows this code! From andy.bauer at kitware.com Wed Dec 3 14:57:14 2014 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 3 Dec 2014 14:57:14 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: <20141203170806.1684765413@mail.rogue-research.com> References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> Message-ID: Hi Sean, I volunteer to look at #3. For some reason I missed this email thread -- thanks for your persistence! Best, Andy On Wed, Dec 3, 2014 at 12:08 PM, Sean McBride wrote: > Thanks David for fixing #2, and thanks Dan Lipsa for doing #3. > > Anyone know vtkPolyLine.cxx to look at #1? > > And to add a #4: > > Common/ExecutionModel/vtkCompositeDataPipeline.cxx:1047:5: Value stored to > 'outputPort' is never read > > The whole block of code seems pointless because nothing actually uses > 'outputPort' after setting it. > > // Save the information about COMPOSITE_INDICES() as needed in the data > // object. > int outputPort = 0; > if(request->Has(FROM_OUTPUT_PORT())) > { > outputPort = request->Get(FROM_OUTPUT_PORT()); > outputPort = (outputPort >= 0 ? outputPort : 0); > } > > Thanks, > > Sean > > > On Fri, 21 Nov 2014 10:20:54 -0700, David Gobbi said: > > >Hi Sean, > > > >I can fix vtkCellPicker.cxx by making the code able to handle the > >case that property is null. > > > > - David > > > > > >On Fri, Nov 21, 2014 at 9:46 AM, Sean McBride > >wrote: > > > >> Hi all, > >> > >> Occasionally, I try to fix some of the hundreds of clang static analyzer > >> warnings in VTK. Some are easy, some are false positives, and some are > >> real problems that I don't know how to fix. I'd like to appeal to you > all > >> to help fix these 3: > >> > >> 1) > >> file: Common/DataModel/vtkPolyLine.cxx > >> method: vtkPolyLine::GenerateSlidingNormals > >> lines: 227-237 > >> problem: dead code. The "if ( largeRotation )" branch sets "theta" then > >> nothing uses it. > >> > >> 2) > >> file: Rendering/Core/vtkCellPicker.cxx > >> method: vtkCellPicker::IntersectVolumeWithLine > >> line: 691 > >> problem: the 'property' pointer is initialized to null, and if the > >> subsequent 'if' is not entered, it's certainly still null at line 691 > and > >> dereferenced. > >> > >> 3) > >> file: Common/DataModel/vtkKdTree.cxx > >> line: 3188 > >> method: vtkKdTree::GenerateRepresentationWholeSpace > >> problem: the first time through the 'for' loop always does "1 << -1". > You > >> can't left shift by a negative count. > >> > >> I don't want to blindly delete dead code that maybe shouldn't be dead, > or > >> just throw in null checks, so hopefully someone knows this code! > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Dec 3 14:59:00 2014 From: sean at rogue-research.com (Sean McBride) Date: Wed, 3 Dec 2014 14:59:00 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> Message-ID: <20141203195900.1287181648@mail.rogue-research.com> Andy, Maybe you have a typo there, but #3 (the kd tree one) was fixed by Dan Lipsa already. #1 and #4 need someone... Sean On Wed, 3 Dec 2014 14:57:14 -0500, Andy Bauer said: >Hi Sean, > >I volunteer to look at #3. For some reason I missed this email thread -- >thanks for your persistence! > >Best, >Andy > >On Wed, Dec 3, 2014 at 12:08 PM, Sean McBride >wrote: > >> Thanks David for fixing #2, and thanks Dan Lipsa for doing #3. >> >> Anyone know vtkPolyLine.cxx to look at #1? >> >> And to add a #4: >> >> Common/ExecutionModel/vtkCompositeDataPipeline.cxx:1047:5: Value stored to >> 'outputPort' is never read >> >> The whole block of code seems pointless because nothing actually uses >> 'outputPort' after setting it. >> >> // Save the information about COMPOSITE_INDICES() as needed in the data >> // object. >> int outputPort = 0; >> if(request->Has(FROM_OUTPUT_PORT())) >> { >> outputPort = request->Get(FROM_OUTPUT_PORT()); >> outputPort = (outputPort >= 0 ? outputPort : 0); >> } >> >> Thanks, >> >> Sean >> >> >> On Fri, 21 Nov 2014 10:20:54 -0700, David Gobbi said: >> >> >Hi Sean, >> > >> >I can fix vtkCellPicker.cxx by making the code able to handle the >> >case that property is null. >> > >> > - David >> > >> > >> >On Fri, Nov 21, 2014 at 9:46 AM, Sean McBride >> >wrote: >> > >> >> Hi all, >> >> >> >> Occasionally, I try to fix some of the hundreds of clang static analyzer >> >> warnings in VTK. Some are easy, some are false positives, and some are >> >> real problems that I don't know how to fix. I'd like to appeal to you >> all >> >> to help fix these 3: >> >> >> >> 1) >> >> file: Common/DataModel/vtkPolyLine.cxx >> >> method: vtkPolyLine::GenerateSlidingNormals >> >> lines: 227-237 >> >> problem: dead code. The "if ( largeRotation )" branch sets "theta" then >> >> nothing uses it. >> >> >> >> 2) >> >> file: Rendering/Core/vtkCellPicker.cxx >> >> method: vtkCellPicker::IntersectVolumeWithLine >> >> line: 691 >> >> problem: the 'property' pointer is initialized to null, and if the >> >> subsequent 'if' is not entered, it's certainly still null at line 691 >> and >> >> dereferenced. >> >> >> >> 3) >> >> file: Common/DataModel/vtkKdTree.cxx >> >> line: 3188 >> >> method: vtkKdTree::GenerateRepresentationWholeSpace >> >> problem: the first time through the 'for' loop always does "1 << -1". >> You >> >> can't left shift by a negative count. >> >> >> >> I don't want to blindly delete dead code that maybe shouldn't be dead, >> or >> >> just throw in null checks, so hopefully someone knows this code! From andy.bauer at kitware.com Wed Dec 3 15:22:51 2014 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 3 Dec 2014 15:22:51 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: <20141203195900.1287181648@mail.rogue-research.com> References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> <20141203195900.1287181648@mail.rogue-research.com> Message-ID: No typo, just poor reading comprehension. I guess I'll make amends and take a look at #1. I'll leave someone else to look at #4 though. On Wed, Dec 3, 2014 at 2:59 PM, Sean McBride wrote: > Andy, > > Maybe you have a typo there, but #3 (the kd tree one) was fixed by Dan > Lipsa already. #1 and #4 need someone... > > Sean > > > On Wed, 3 Dec 2014 14:57:14 -0500, Andy Bauer said: > > >Hi Sean, > > > >I volunteer to look at #3. For some reason I missed this email thread -- > >thanks for your persistence! > > > >Best, > >Andy > > > >On Wed, Dec 3, 2014 at 12:08 PM, Sean McBride > >wrote: > > > >> Thanks David for fixing #2, and thanks Dan Lipsa for doing #3. > >> > >> Anyone know vtkPolyLine.cxx to look at #1? > >> > >> And to add a #4: > >> > >> Common/ExecutionModel/vtkCompositeDataPipeline.cxx:1047:5: Value stored > to > >> 'outputPort' is never read > >> > >> The whole block of code seems pointless because nothing actually uses > >> 'outputPort' after setting it. > >> > >> // Save the information about COMPOSITE_INDICES() as needed in the data > >> // object. > >> int outputPort = 0; > >> if(request->Has(FROM_OUTPUT_PORT())) > >> { > >> outputPort = request->Get(FROM_OUTPUT_PORT()); > >> outputPort = (outputPort >= 0 ? outputPort : 0); > >> } > >> > >> Thanks, > >> > >> Sean > >> > >> > >> On Fri, 21 Nov 2014 10:20:54 -0700, David Gobbi said: > >> > >> >Hi Sean, > >> > > >> >I can fix vtkCellPicker.cxx by making the code able to handle the > >> >case that property is null. > >> > > >> > - David > >> > > >> > > >> >On Fri, Nov 21, 2014 at 9:46 AM, Sean McBride > > >> >wrote: > >> > > >> >> Hi all, > >> >> > >> >> Occasionally, I try to fix some of the hundreds of clang static > analyzer > >> >> warnings in VTK. Some are easy, some are false positives, and some > are > >> >> real problems that I don't know how to fix. I'd like to appeal to > you > >> all > >> >> to help fix these 3: > >> >> > >> >> 1) > >> >> file: Common/DataModel/vtkPolyLine.cxx > >> >> method: vtkPolyLine::GenerateSlidingNormals > >> >> lines: 227-237 > >> >> problem: dead code. The "if ( largeRotation )" branch sets "theta" > then > >> >> nothing uses it. > >> >> > >> >> 2) > >> >> file: Rendering/Core/vtkCellPicker.cxx > >> >> method: vtkCellPicker::IntersectVolumeWithLine > >> >> line: 691 > >> >> problem: the 'property' pointer is initialized to null, and if the > >> >> subsequent 'if' is not entered, it's certainly still null at line 691 > >> and > >> >> dereferenced. > >> >> > >> >> 3) > >> >> file: Common/DataModel/vtkKdTree.cxx > >> >> line: 3188 > >> >> method: vtkKdTree::GenerateRepresentationWholeSpace > >> >> problem: the first time through the 'for' loop always does "1 << -1". > >> You > >> >> can't left shift by a negative count. > >> >> > >> >> I don't want to blindly delete dead code that maybe shouldn't be > dead, > >> or > >> >> just throw in null checks, so hopefully someone knows this code! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Dec 4 12:47:19 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 4 Dec 2014 12:47:19 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: <20141203170806.1684765413@mail.rogue-research.com> References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> Message-ID: It seems to be a copy & paste & edit issue. That can be deleted without any side effects. I am happy to do it but I am unlikely to get to it for a week or two. -berk On Wed, Dec 3, 2014 at 12:08 PM, Sean McBride wrote: > Thanks David for fixing #2, and thanks Dan Lipsa for doing #3. > > Anyone know vtkPolyLine.cxx to look at #1? > > And to add a #4: > > Common/ExecutionModel/vtkCompositeDataPipeline.cxx:1047:5: Value stored to > 'outputPort' is never read > > The whole block of code seems pointless because nothing actually uses > 'outputPort' after setting it. > > // Save the information about COMPOSITE_INDICES() as needed in the data > // object. > int outputPort = 0; > if(request->Has(FROM_OUTPUT_PORT())) > { > outputPort = request->Get(FROM_OUTPUT_PORT()); > outputPort = (outputPort >= 0 ? outputPort : 0); > } > > Thanks, > > Sean > > > On Fri, 21 Nov 2014 10:20:54 -0700, David Gobbi said: > > >Hi Sean, > > > >I can fix vtkCellPicker.cxx by making the code able to handle the > >case that property is null. > > > > - David > > > > > >On Fri, Nov 21, 2014 at 9:46 AM, Sean McBride > >wrote: > > > >> Hi all, > >> > >> Occasionally, I try to fix some of the hundreds of clang static analyzer > >> warnings in VTK. Some are easy, some are false positives, and some are > >> real problems that I don't know how to fix. I'd like to appeal to you > all > >> to help fix these 3: > >> > >> 1) > >> file: Common/DataModel/vtkPolyLine.cxx > >> method: vtkPolyLine::GenerateSlidingNormals > >> lines: 227-237 > >> problem: dead code. The "if ( largeRotation )" branch sets "theta" then > >> nothing uses it. > >> > >> 2) > >> file: Rendering/Core/vtkCellPicker.cxx > >> method: vtkCellPicker::IntersectVolumeWithLine > >> line: 691 > >> problem: the 'property' pointer is initialized to null, and if the > >> subsequent 'if' is not entered, it's certainly still null at line 691 > and > >> dereferenced. > >> > >> 3) > >> file: Common/DataModel/vtkKdTree.cxx > >> line: 3188 > >> method: vtkKdTree::GenerateRepresentationWholeSpace > >> problem: the first time through the 'for' loop always does "1 << -1". > You > >> can't left shift by a negative count. > >> > >> I don't want to blindly delete dead code that maybe shouldn't be dead, > or > >> just throw in null checks, so hopefully someone knows this code! > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Dec 5 12:23:05 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 5 Dec 2014 12:23:05 -0500 Subject: [vtk-developers] trouble with file writers and error handling Message-ID: <20141205172305.285815752@mail.rogue-research.com> Hi all, How is one supposed to check errors when using say vtkSTLWriter? The docs for "int vtkWriter::Write ( )" say "Returns 1 on success and 0 on failure" which I thought was sufficient to know at least success/fail. But it's implementation is: int vtkWriter::Write() { // Make sure we have input. if (this->GetNumberOfInputConnections(0) < 1) { vtkErrorMacro("No input provided!"); return 0; } // always write even if the data hasn't changed this->Modified(); this->UpdateWholeExtent(); return 1; } So it basically always returns success. :( vtkSTLWriter::WriteData()'s implementation calls a lot of this: this->SetErrorCode(vtkErrorCode::NoFileNameError); So is one expected to call GetErrorCode() after Write()? Should vtkWriter::Write() be changed to return something like: return (this->GetErrorCode == vtkErrorCode::NoError); 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 david.gobbi at gmail.com Fri Dec 5 14:38:04 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 5 Dec 2014 12:38:04 -0700 Subject: [vtk-developers] trouble with file writers and error handling In-Reply-To: <20141205172305.285815752@mail.rogue-research.com> References: <20141205172305.285815752@mail.rogue-research.com> Message-ID: On Fri, Dec 5, 2014 at 10:23 AM, Sean McBride wrote: > > > So is one expected to call GetErrorCode() after Write()? > Yes, but even that is probably insufficient for many of the writers because not all writers set the ErrorCode. The most robust way to check for errors is to add an observer that catches ErrorEvent. Should vtkWriter::Write() be changed to return something like: > > return (this->GetErrorCode == vtkErrorCode::NoError); > This sounds like a good idea. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff.baumes at kitware.com Fri Dec 5 18:04:21 2014 From: jeff.baumes at kitware.com (Jeff Baumes) Date: Fri, 05 Dec 2014 23:04:21 +0000 Subject: [vtk-developers] Missing "Infovis" classes References: Message-ID: I'd be glad to take a look. Some of those are at least somewhat familiar to me. On Tue, Dec 2, 2014 at 11:11 AM Bill Lorensen wrote: > Folks, > A user just reported that vtkConvexHull2D was not being compiled. > After further investigation,, I see that the following classes are in > the Infovis/Core directory, but are not being compiled: > vtkConvexHull2D > vtkDotProductSimilarity > vtkGraphAnnotationLayersFilter > vtkTransferAttributes > > Looks to me that vtkConvexHull2D and vtkGraphAnnotationLayersFilter > should be moved into Rendering/Annotation. > > I'll be happy to work on a patch. > > Bill > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanakas at gmx.ch Tue Dec 9 05:38:01 2014 From: tanakas at gmx.ch (Tanaka Simon) Date: Tue, 09 Dec 2014 11:38:01 +0100 Subject: [vtk-developers] Fwd: Re: [vtkusers] segfault when vtkXMLMultiBlockDataReader reads a .vtm binary mode - bug? In-Reply-To: <54594649.2000401@gmx.ch> References: <54594649.2000401@gmx.ch> Message-ID: <5486D109.2070504@gmx.ch> Dear Developers and Users, I'll warming up this issue again since there was no echo last time. Can somebody confirm the buggy behaviour of the following code: #include #include #include #include #include #include #include #include #include int main(int, char *[]) { /** * notes: * -> it works with ascii writer configuration for any M,N. * -> with binary writer configuration it segfaults for higher M,N * -> {N=100,M=1} works. {N=100,M=10} fails. {N=1000,M=1} fails. */ const unsigned int N = 1000; // number of points const unsigned int M = 1; // number of characters in the string std::string filename = "test_output.vtm"; std::stringstream mystring; struct stat buffer; vtkSmartPointer points = vtkSmartPointer::New(); vtkSmartPointer stringAttribute = vtkSmartPointer::New(); vtkSmartPointer mypolydata = vtkSmartPointer::New(); vtkSmartPointer multiBDS = vtkSmartPointer::New (); vtkSmartPointer writer = vtkSmartPointer::New(); vtkSmartPointer multiBDS_read = vtkSmartPointer::New (); vtkSmartPointer reader = vtkSmartPointer::New(); stringAttribute->SetNumberOfComponents(1); reader->SetFileName(filename.c_str()); writer->SetFileName(filename.c_str()); writer->SetDataModeToBinary(); // segfault //writer->SetDataModeToAscii(); // works // create some points: for (int k=0; kInsertNextPoint(0.0, 0.0, 0.0); } // create some string attributes: for (int k=0; kInsertNextValue(mystring.str().c_str()); } // assemble and write to file: mypolydata->SetPoints(points); mypolydata->GetPointData()->AddArray(stringAttribute); multiBDS->SetBlock(0,mypolydata); writer->SetInput(multiBDS); writer->Write(); //now read the file again: if (stat (filename.c_str(), &buffer) == 0) { reader->Update(); multiBDS_read->ShallowCopy(reader->GetOutput()); } else { std::cout<<"file not found."< To: VTK Users , vtk-developers at vtk.org Dear Developers, can somebody confirm the buggy behaviour? i attached a yet simplified code to reproduce the segfault. thanks simon btw: i use ubuntu 14.04 and gcc 4.7 On 03.11.2014 11:19, Tanaka Simon wrote: > Dear Developers, > > Hello VTK users and developers, > > I attached a simple program which segfaults. please also have a look > at the comments in the code. > > i want to: > 1) write a vtkMultiBlockDataSet to a file > 2) load it > > it only segfaults if the writer is set to binary mode, and only if the > data exceeds a certain size. in ascii mode, everything is fine. > > > this might be related: > http://www.paraview.org/Bug/print_bug_page.php?bug_id=13294 > > > can you confirm that behaviour? what am i doing wrong? and if it is a > bug, how can i work around? > > thank you very much > simon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8) PROJECT(vtk_weird_segfault) find_package(VTK REQUIRED) include(${VTK_USE_FILE}) add_executable(vtk_weird_segfault MACOSX_BUNDLE vtk_weird_segfault) if(VTK_LIBRARIES) target_link_libraries(vtk_weird_segfault ${VTK_LIBRARIES}) else() target_link_libraries(vtk_weird_segfault vtkHybrid vtkWidgets) endif() -------------- next part -------------- A non-text attachment was scrubbed... Name: vtk_weird_segfault.cxx Type: text/x-c++src Size: 2546 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ 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 Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtkusers From david.gobbi at gmail.com Tue Dec 9 09:30:28 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 9 Dec 2014 07:30:28 -0700 Subject: [vtk-developers] Wrapping enum types In-Reply-To: References: Message-ID: I've merged the fixes for the Java and Tcl wrappers so that they can wrap methods that take enum types as parameters. Together with the python fixes, this means that there should be no barrier to people who want to use enum types in their class interfaces. On Tue, Dec 2, 2014 at 9:17 PM, David Gobbi wrote: > Thanks, Marcus. I've been thinking about Java and Tcl, and I might > implement enums in those wrappers via a simple type cast. > > For example, > > void SetColorMode(ColorModeEnum val); > > would be called from the Tcl and Java wrappers like this > > SetColorMode(static_cast(val)); > > with no type checking. It would be much easier to implement > than making each enum into a first-class type like I've done > for the Python wrappers. > > - David > > > On Tue, Dec 2, 2014 at 9:01 PM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> Hi David, >> >> I will try to take a look soon, travel and proposals have taken up >> more of my time than I might like. I am really pleased to see this >> added to the Python wrapping (although in truth would love to see it >> in Java/Tcl so we could actually use it in our API). >> >> Marcus >> >> On Tue, Dec 2, 2014 at 11:46 AM, David Gobbi >> wrote: >> > Still waiting for reviewers for >> http://review.source.kitware.com/#/c/17993 >> > (refactoring the python wrappers and wrapping enum types). Big thanks >> > to Ben for his comments so far. >> > >> > - David >> > >> > >> > On Fri, Nov 21, 2014 at 10:58 AM, David Gobbi >> wrote: >> >> >> >> Hi All, >> >> >> >> The enum support for the wrappers is done (pending merge). The caveat >> >> that I mentioned in my previous email no longer applies, i.e. with this >> >> new >> >> patch _all_ enum types are wrapped, whether they are in the global >> >> namespace, in a class namespace, or in any other namespace (except for >> >> nested namespaces, which aren't supported by the wrappers yet). >> >> >> >> This change isn't going to have much impact on the VTK core, because >> >> most VTK class methods simply take "int" parameters instead of >> requiring >> >> the use of enums. However, it will have a _big_ impact for the >> wrapping >> >> of third-party VTK classes which tend to use enum parameters quite >> often. >> >> (In fact the change was motivated by the need to wrap some of my own >> >> external classes). >> >> >> >> Enum parameter support is only provided for the python wrappers, not >> for >> >> Java or Tcl. >> >> >> >> - David >> >> >> >> >> >> On Mon, Nov 17, 2014 at 7:04 AM, David Gobbi >> >> wrote: >> >>> >> >>> Hi All, >> >>> >> >>> I have a patch in gerrit that modifies the python wrappers so that >> enum >> >>> types are wrapped. This means that method parameters can be enum >> >>> types, something that wasn't possible for wrapped methods before. >> >>> http://review.source.kitware.com/#/c/17993 >> >>> >> >>> E.g.: >> >>> >> >>> class vtkSomeObject >> >>> { >> >>> public: >> >>> enum ColorEnum { Red, Blue }; >> >>> void SetColor(enum ColorEnum); >> >>> }; >> >>> >> >>> Each enum type is wrapped as a unique python type subclassed from >> >>> python's "int" type. So an enum can be used wherever an int can be >> >>> used, but methods that take an enum will raise a TypeError unless >> >>> given a value of the correct enum type. >> >>> >> >>> One caveat is that this only works if the method and the enum type are >> >>> members of the same class. Sometime later I'll generalize it so that >> a >> >>> method can use an enum defined in a different class, but method & enum >> >>> in the same class seems to be the most common use case. >> >>> >> >>> Cheers, >> >>> >> >>> - David >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Dec 9 09:49:59 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 9 Dec 2014 07:49:59 -0700 Subject: [vtk-developers] Wrapping enum types In-Reply-To: References: Message-ID: You rock David. -berk On Tue, Dec 9, 2014 at 7:30 AM, David Gobbi wrote: > I've merged the fixes for the Java and Tcl wrappers so that they can wrap > methods that take enum types as parameters. Together with the python > fixes, this means that there should be no barrier to people who want to use > enum types in their class interfaces. > > > On Tue, Dec 2, 2014 at 9:17 PM, David Gobbi wrote: > >> Thanks, Marcus. I've been thinking about Java and Tcl, and I might >> implement enums in those wrappers via a simple type cast. >> >> For example, >> >> void SetColorMode(ColorModeEnum val); >> >> would be called from the Tcl and Java wrappers like this >> >> SetColorMode(static_cast(val)); >> >> with no type checking. It would be much easier to implement >> than making each enum into a first-class type like I've done >> for the Python wrappers. >> >> - David >> >> >> On Tue, Dec 2, 2014 at 9:01 PM, Marcus D. Hanwell < >> marcus.hanwell at kitware.com> wrote: >> >>> Hi David, >>> >>> I will try to take a look soon, travel and proposals have taken up >>> more of my time than I might like. I am really pleased to see this >>> added to the Python wrapping (although in truth would love to see it >>> in Java/Tcl so we could actually use it in our API). >>> >>> Marcus >>> >>> On Tue, Dec 2, 2014 at 11:46 AM, David Gobbi >>> wrote: >>> > Still waiting for reviewers for >>> http://review.source.kitware.com/#/c/17993 >>> > (refactoring the python wrappers and wrapping enum types). Big thanks >>> > to Ben for his comments so far. >>> > >>> > - David >>> > >>> > >>> > On Fri, Nov 21, 2014 at 10:58 AM, David Gobbi >>> wrote: >>> >> >>> >> Hi All, >>> >> >>> >> The enum support for the wrappers is done (pending merge). The caveat >>> >> that I mentioned in my previous email no longer applies, i.e. with >>> this >>> >> new >>> >> patch _all_ enum types are wrapped, whether they are in the global >>> >> namespace, in a class namespace, or in any other namespace (except for >>> >> nested namespaces, which aren't supported by the wrappers yet). >>> >> >>> >> This change isn't going to have much impact on the VTK core, because >>> >> most VTK class methods simply take "int" parameters instead of >>> requiring >>> >> the use of enums. However, it will have a _big_ impact for the >>> wrapping >>> >> of third-party VTK classes which tend to use enum parameters quite >>> often. >>> >> (In fact the change was motivated by the need to wrap some of my own >>> >> external classes). >>> >> >>> >> Enum parameter support is only provided for the python wrappers, not >>> for >>> >> Java or Tcl. >>> >> >>> >> - David >>> >> >>> >> >>> >> On Mon, Nov 17, 2014 at 7:04 AM, David Gobbi >>> >> wrote: >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I have a patch in gerrit that modifies the python wrappers so that >>> enum >>> >>> types are wrapped. This means that method parameters can be enum >>> >>> types, something that wasn't possible for wrapped methods before. >>> >>> http://review.source.kitware.com/#/c/17993 >>> >>> >>> >>> E.g.: >>> >>> >>> >>> class vtkSomeObject >>> >>> { >>> >>> public: >>> >>> enum ColorEnum { Red, Blue }; >>> >>> void SetColor(enum ColorEnum); >>> >>> }; >>> >>> >>> >>> Each enum type is wrapped as a unique python type subclassed from >>> >>> python's "int" type. So an enum can be used wherever an int can be >>> >>> used, but methods that take an enum will raise a TypeError unless >>> >>> given a value of the correct enum type. >>> >>> >>> >>> One caveat is that this only works if the method and the enum type >>> are >>> >>> members of the same class. Sometime later I'll generalize it so >>> that a >>> >>> method can use an enum defined in a different class, but method & >>> enum >>> >>> in the same class seems to be the most common use case. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> - David >>> >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Dec 9 10:54:02 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 9 Dec 2014 08:54:02 -0700 Subject: [vtk-developers] TestGDALRasterReader Message-ID: The test for vtkGDALRasterReader has been failing ever since it was merged. It also shows memory leaks with valgrind: http://open.cdash.org/viewDynamicAnalysisFile.php?id=3325863 It looks like its input data is missing. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu at rogue-research.com Tue Dec 9 13:24:36 2014 From: mathieu at rogue-research.com (Mathieu Coursolle) Date: Tue, 9 Dec 2014 13:24:36 -0500 Subject: [vtk-developers] Crash in vtkImageStencil after update to VTK 6 Message-ID: Hi, We are currently upgrading an application from VTK 5.10 to VTK 6. We have a piece of code that uses vtkPolyDataToImageStencil and vtkImageStencil, which worked perfectly when using VTK 5.10. However, it now crashes in some cases since we upgraded to VTK 6. Here is a summary of the workflow and code: 1) We load a polydata (output from another algorithm). 2) We create an image and fill its data with a constant value (0xFF). vtkSmartPointer image = vtkSmartPointer::New(); image->SetDimensions(sizeX, sizeY, sizeZ); image->SetSpacing(spacingX, spacingY, spacingZ); image->SetOrigin(0.0, 0.0, 0.0); image->AllocateScalars(VTK_UNSIGNED_CHAR, 1); void* dataPtr = image->GetScalarPointer(); memset(dataPtr, 0xFF, sizeX * sizeY * sizeZ); 3) We apply the polydata to image stencil: vtkSmartPointer dataStencil = vtkSmartPointer::New(); dataStencil->SetInputData(polydata); dataStencil->SetInformationInput(image); 4) We apply the image stencil. vtkSmartPointer stencil = vtkSmartPointer::New(); stencil->SetStencilConnection(dataStencil->GetOutputPort()); stencil->SetInputData(image); stencil->SetBackgroundValue(0); stencil->Update(); vtkSmartPointer mask = stencil->GetOutput(); It still works fine with some of the polydata, but now crashes in vtkImageStencil execution, more precisely in vtkCopyPixel, with at least one of the polydata that worked fine before. One thing I noticed is that the polydata for which it fails has its bounds very close to the edge of the image. I changed the tolerance (dataStencil->SetTolerance()) to 0 and it seems to fix the issue, but I have to admit that I don't understand why. That being said, anyone have an idea of why it would crash with VTK 6 and not before? I saw that there was a change in the way the tolerance was managed, but couldn't track it down specifically to our issue. Thank you for you help, Mathieu _________________________ Mathieu Coursolle, Eng., M.Eng. R&D Manager Rogue Research Inc. www.rogue-research.com +1 514 284 3888 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff.baumes at kitware.com Tue Dec 9 14:34:27 2014 From: jeff.baumes at kitware.com (Jeff Baumes) Date: Tue, 09 Dec 2014 19:34:27 +0000 Subject: [vtk-developers] Missing "Infovis" classes References: Message-ID: Looks like you beat me to the punch Bill, I see they are in now. On Fri Dec 05 2014 at 6:04:21 PM Jeff Baumes wrote: > I'd be glad to take a look. Some of those are at least somewhat familiar > to me. > On Tue, Dec 2, 2014 at 11:11 AM Bill Lorensen > wrote: > >> Folks, >> A user just reported that vtkConvexHull2D was not being compiled. >> After further investigation,, I see that the following classes are in >> the Infovis/Core directory, but are not being compiled: >> vtkConvexHull2D >> vtkDotProductSimilarity >> vtkGraphAnnotationLayersFilter >> vtkTransferAttributes >> >> Looks to me that vtkConvexHull2D and vtkGraphAnnotationLayersFilter >> should be moved into Rendering/Annotation. >> >> I'll be happy to work on a patch. >> >> Bill >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Dec 9 14:49:44 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 10 Dec 2014 06:49:44 +1100 Subject: [vtk-developers] Static Analysis of VTK Message-ID: Sean, You are doing an awesome job cleaning up VTK! I, for one, deeply appreciate what you are doing. Regards Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Dec 9 14:56:31 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Dec 2014 14:56:31 -0500 Subject: [vtk-developers] Static Analysis of VTK In-Reply-To: References: Message-ID: +1 On Tue, Dec 9, 2014 at 2:49 PM, Andrew Maclean wrote: > Sean, > You are doing an awesome job cleaning up VTK! > I, for one, deeply appreciate what you are doing. > > Regards > Andrew > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Tue Dec 9 15:03:53 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 9 Dec 2014 15:03:53 -0500 Subject: [vtk-developers] Static Analysis of VTK In-Reply-To: References: Message-ID: +1 David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Dec 9, 2014 at 2:56 PM, Bill Lorensen wrote: > +1 > > > On Tue, Dec 9, 2014 at 2:49 PM, Andrew Maclean > wrote: > > Sean, > > You are doing an awesome job cleaning up VTK! > > I, for one, deeply appreciate what you are doing. > > > > Regards > > Andrew > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From afalahat at uci.edu Tue Dec 9 16:16:09 2014 From: afalahat at uci.edu (Ahmad Falahatpisheh) Date: Tue, 9 Dec 2014 13:16:09 -0800 Subject: [vtk-developers] Looking for a VTK/ITK Professional Developer Message-ID: <00fa01d013f5$5aae6c00$100b4400$@uci.edu> Dear VTK developers, I am the co-founder of a start-up company in California. We are recruiting a professional VTK/ITK developer to develop a visualization GUI for medical imaging. If you are interetsed please send your resumes to: a f a l a h a t @ u c i . e d u (please remove the white spaces in the email address). I would be happy to provide more info upon request. Looking forward to hearing from interested developers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.morency at gmail.com Tue Dec 9 16:25:02 2014 From: felix.morency at gmail.com (=?UTF-8?Q?F=C3=A9lix_C=2E_Morency?=) Date: Tue, 9 Dec 2014 16:25:02 -0500 Subject: [vtk-developers] Looking for a VTK/ITK Professional Developer In-Reply-To: <00fa01d013f5$5aae6c00$100b4400$@uci.edu> References: <00fa01d013f5$5aae6c00$100b4400$@uci.edu> Message-ID: Could you provide a job offer description that I could diffuse it in my network? Thanks, -F On Tue, Dec 9, 2014 at 4:16 PM, Ahmad Falahatpisheh wrote: > Dear VTK developers, > > > > I am the co-founder of a start-up company in California. We are recruiting > a professional VTK/ITK developer to develop a visualization GUI for medical > imaging. If you are interetsed please send your resumes to: a f a l a h a > t @ u c i . e d u (please remove the white spaces in the email address). I > would be happy to provide more info upon request. > > > > Looking forward to hearing from interested developers. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- F?lix C. Morency, M.Sc. Plateforme d?analyse et de visualisation d?images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique ?tienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue Dec 9 17:18:54 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 9 Dec 2014 17:18:54 -0500 Subject: [vtk-developers] TestGDALRasterReader In-Reply-To: References: Message-ID: David, Will push a fix. Didn't that one of the dashboard was building and using the GDAL. I am on travel today but will try to push a fix tomorrow. Thanks, On Tue, Dec 9, 2014 at 10:54 AM, David Gobbi wrote: > The test for vtkGDALRasterReader has been failing ever since it was > merged. It also shows memory leaks with valgrind: > http://open.cdash.org/viewDynamicAnalysisFile.php?id=3325863 > > It looks like its input data is missing. > > - David > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Tue Dec 9 17:29:34 2014 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Tue, 9 Dec 2014 15:29:34 -0700 Subject: [vtk-developers] [vtkusers] Static Analysis of VTK In-Reply-To: References: Message-ID: Thanks Sean, Bill, Andrew, David G. and all others that I'm forgetting here who contributes to VTK. I guess, I'm just following that stream. But it is true that it is important to share our appreciation. Seb On Tue, Dec 9, 2014 at 1:03 PM, David E DeMarle wrote: > +1 > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Dec 9, 2014 at 2:56 PM, Bill Lorensen > wrote: > >> +1 >> >> >> On Tue, Dec 9, 2014 at 2:49 PM, Andrew Maclean >> wrote: >> > Sean, >> > You are doing an awesome job cleaning up VTK! >> > I, for one, deeply appreciate what you are doing. >> > >> > Regards >> > Andrew >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://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 > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Dec 9 17:39:45 2014 From: sean at rogue-research.com (Sean McBride) Date: Tue, 9 Dec 2014 17:39:45 -0500 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> Message-ID: <20141209223945.2143611529@mail.rogue-research.com> Hi, Thanks all for your help with these. Everything I've mentioned so far is fixed, yay! Here's a new batch of suspicious dead code, that I'm not comfortable just removing (though it's certainly dead). If you are an expert in any of the classes below, can you svp take a look? 5a) Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:141:9: Value stored to 'result' is never read 5b) Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:291:11: Value stored to 'result' is never read 6a) Interaction/Widgets/vtkSphereRepresentation.cxx:530:5: Value stored to 'radius' is never read 6b) Interaction/Widgets/vtkSphereWidget.cxx:716:5: Value stored to 'radius' is never read 7) Interaction/Widgets/vtkPointHandleRepresentation3D.cxx:277:20: Value stored to 'path' during its initialization is never read 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 sean at rogue-research.com Tue Dec 9 18:05:46 2014 From: sean at rogue-research.com (Sean McBride) Date: Tue, 9 Dec 2014 18:05:46 -0500 Subject: [vtk-developers] kamino.kitware dashboard poorly named submission... Message-ID: <20141209230546.1570153853@mail.rogue-research.com> Hi all, See: The page has 3 confusing lines, pasted here: Build Name: Mac10.7.5-gcc-release-x86_64-nightly_master (view notes) Compiler Version: unknown -- The CXX compiler identification is Clang 3.1.0 So two issues: 1) if this machine is really using clang, I dare say "gcc" should not be in its submission name :) 2) why does it say "Compiler Version: unknown". Is that cdash or cmake's fault? 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 Grant.Windes at smith-nephew.com Tue Dec 9 19:22:16 2014 From: Grant.Windes at smith-nephew.com (Windes, Grant) Date: Wed, 10 Dec 2014 00:22:16 +0000 Subject: [vtk-developers] VTK 6.1 python examples Message-ID: I've been working on migrating our application (written in python) from vtk 5.10 to vtk 6.1 All the python examples that I have read through on the vtk wiki are still using vtk 5 syntax (http://vtk.org/Wiki/VTK/Examples/Python/GeometricObjects/Display/Cube) What's the best way to go about updating these to both support vtk 5 and support vtk 6+ Any preference about updating the wiki pages? Or maybe I am missing the location of the vtk6 python examples 1. Fix something in the current build system? 2. Create separate examples for vtk5 and vtk6 3. Use if check (Seems like it could get messy) if VTK_MAJOR_VERSION <= 5: current vtk code else: vtk6+ code -Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Dec 9 21:14:00 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Dec 2014 21:14:00 -0500 Subject: [vtk-developers] VTK 6.1 python examples In-Reply-To: References: Message-ID: You can edit the examples on the wiki. For the c++ examples we use offers to support vtk5 and 6. On Dec 9, 2014 8:55 PM, "Windes, Grant" wrote: > I?ve been working on migrating our application (written in python) from > vtk 5.10 to vtk 6.1 > > > > All the python examples that I have read through on the vtk wiki are still > using vtk 5 syntax ( > http://vtk.org/Wiki/VTK/Examples/Python/GeometricObjects/Display/Cube) > > > > What?s the best way to go about updating these to both support vtk 5 and > support vtk 6+ > > > > Any preference about updating the wiki pages? Or maybe I am missing the > location of the vtk6 python examples > > > > 1. Fix something in the current build system? > > 2. Create separate examples for vtk5 and vtk6 > > 3. Use if check (Seems like it could get messy) > > if VTK_MAJOR_VERSION <= 5: > > current vtk > > code else: > > vtk6+ code > > > > -Grant > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yue.nicholas at gmail.com Wed Dec 10 04:18:45 2014 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Wed, 10 Dec 2014 20:18:45 +1100 Subject: [vtk-developers] VTK 6.1 - OS X Yosemite Message-ID: <54880FF5.5080708@gmail.com> Hi, Is there a patch for VTK 6.1 to build on OS X Yosemite ? I am getting the following errors [ 22%] Building CXX object Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/vtkCocoaRenderWindowInteractor.mm.o error: garbage collection is no longer supported make[2]: *** [Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/vtkCocoaRenderWindowInteractor.mm.o] Error 1 make[1]: *** [Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/all] Error 2 make: *** [all] Error 2 Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools From cameron.palmer at ntnu.no Wed Dec 10 07:18:05 2014 From: cameron.palmer at ntnu.no (Cameron Lowell Palmer) Date: Wed, 10 Dec 2014 12:18:05 +0000 Subject: [vtk-developers] VES/VTK Actors and Data Representation Message-ID: <696C2D29-CEFC-47DB-900A-8717099B94B5@ntnu.no> I?ve gotten my augmented reality project moving forward and have video in the scene, my 3D model objects, and I?m using OpenCV to pass in rotation and translation of a frame marker with respect the the camera matrix. Now I?m trying to figure out how to put-it-all-together. The question: I have the video image in a vesKiwiImagePlaneDataRepresentation and want that to fill the screen. I see that I can translate the object, but is there a simple way to lock the movement of the actor to fill the camera scene edge to edge? Converting my OpenCV coordinates into terms of the VES/Kiwi projection. Is there a facility for that? Thanks in advance, Cameron From robert.maynard at kitware.com Wed Dec 10 08:59:08 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Dec 2014 08:59:08 -0500 Subject: [vtk-developers] VTK 6.1 - OS X Yosemite In-Reply-To: <54880FF5.5080708@gmail.com> References: <54880FF5.5080708@gmail.com> Message-ID: Set VTK_REQUIRED_OBJCXX_FLAGS to "" when configuring vtk. This issue has been fixed in vtk master and will be in the next vtk release. On Wed, Dec 10, 2014 at 4:18 AM, Nicholas Yue wrote: > Hi, > > Is there a patch for VTK 6.1 to build on OS X Yosemite ? > > I am getting the following errors > > [ 22%] Building CXX object > Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/vtkCocoaRenderWindowInteractor.mm.o > error: garbage collection is no longer supported > make[2]: *** > [Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/vtkCocoaRenderWindowInteractor.mm.o] > Error 1 > make[1]: *** [Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/all] Error > 2 > make: *** [all] Error 2 > > > Cheers > > -- > Nicholas Yue > Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 > Custom Dev - C++ porting, OSX, Linux, Windows > http://au.linkedin.com/in/nicholasyue > https://vimeo.com/channels/naiadtools > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From berk.geveci at kitware.com Wed Dec 10 10:30:14 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Dec 2014 08:30:14 -0700 Subject: [vtk-developers] Need help with a few clang analyzer warnings In-Reply-To: <20141209223945.2143611529@mail.rogue-research.com> References: <20141121164611.1400065013@mail.rogue-research.com> <20141203170806.1684765413@mail.rogue-research.com> <20141209223945.2143611529@mail.rogue-research.com> Message-ID: Hi Sean, 5a and 5b look very suspicious. Let me track those down next week. Best, -berk On Tue, Dec 9, 2014 at 3:39 PM, Sean McBride wrote: > Hi, > > Thanks all for your help with these. Everything I've mentioned so far is > fixed, yay! Here's a new batch of suspicious dead code, that I'm not > comfortable just removing (though it's certainly dead). If you are an > expert in any of the classes below, can you svp take a look? > > 5a) Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:141:9: > Value stored to 'result' is never read > > 5b) Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:291:11: > Value stored to 'result' is never read > > 6a) Interaction/Widgets/vtkSphereRepresentation.cxx:530:5: Value stored to > 'radius' is never read > > 6b) Interaction/Widgets/vtkSphereWidget.cxx:716:5: Value stored to > 'radius' is never read > > 7) Interaction/Widgets/vtkPointHandleRepresentation3D.cxx:277:20: Value > stored to 'path' during its initialization is never read > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Dec 10 17:18:19 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 11 Dec 2014 09:18:19 +1100 Subject: [vtk-developers] VTK 6.1 python examples Message-ID: Hi Grant, I think you will find that most of the recent submissions support either VTK 6.1 or more recent. I for one have not bothered writing compatible versions for VTK 5.x. I also have adopted this approach in writing the C++ examples. I refer you to the following discussion that we had a while back regarding supporting different versions of Python: http://markmail.org/message/43hbrqh3tu4nmig3 The upshot of this is that it is just not possible to support different versions of Python within the code itself since python has no equivalents "#if" or "#ifdef", from this discussion you will also see that your Option 3 will not work. The implication here is that the approach used in the C++ examples using #ifdef for pipeline differences will not work in Python. In one or two cases I have used an approach like this: def CheckVTKVersion(requiredMajorVersion): ''' Check the VTK version. :param: requiredMajorVersion e.g. 6 ''' version = vtk.vtkVersion() if version.GetVTKMajorVersion() > requiredMajorVersion: raise else: return if __name__ == '__main__': try: CheckVTKVersion(6) except: print "You need VTK Version 6 or greater." print "The class vtkNamedColors is in VTK version 6 or greater." exit(0) iren = main() iren.Start() This code would give errors anyway if run under VTK5 because of the pipeline re-architecture so it is of more use for checking for 6.2 features. My preference would be to just update the examples to VTK 6. In most cases it is a fairly straight forward process. I think creating separate examples for VTK5 and VTK6 would be a lot of work for very little return, given that people seem to be migrating to VTK6 anyway and new users should be using VTK6. Regards Andrew > ---------- Forwarded message ---------- > From: "Windes, Grant" > To: "vtk-developers at vtk.org" > Cc: > Date: Wed, 10 Dec 2014 00:22:16 +0000 > Subject: [vtk-developers] VTK 6.1 python examples > > I?ve been working on migrating our application (written in python) from > vtk 5.10 to vtk 6.1 > > > > All the python examples that I have read through on the vtk wiki are still > using vtk 5 syntax ( > http://vtk.org/Wiki/VTK/Examples/Python/GeometricObjects/Display/Cube) > > > > What?s the best way to go about updating these to both support vtk 5 and > support vtk 6+ > > > > Any preference about updating the wiki pages? Or maybe I am missing the > location of the vtk6 python examples > > > > 1. Fix something in the current build system? > > 2. Create separate examples for vtk5 and vtk6 > > 3. Use if check (Seems like it could get messy) > > if VTK_MAJOR_VERSION <= 5: > > current vtk > > code else: > > vtk6+ code > > > > -Grant > > > > > ---------- Forwarded message ---------- > From: Bill Lorensen > To: "Windes, Grant" > Cc: VTK Developers > Date: Tue, 9 Dec 2014 21:14:00 -0500 > Subject: Re: [vtk-developers] VTK 6.1 python examples > > You can edit the examples on the wiki. For the c++ examples we use offers > to support vtk5 and 6. > On Dec 9, 2014 8:55 PM, "Windes, Grant" > wrote: > >> I?ve been working on migrating our application (written in python) from >> vtk 5.10 to vtk 6.1 >> >> >> >> All the python examples that I have read through on the vtk wiki are >> still using vtk 5 syntax ( >> http://vtk.org/Wiki/VTK/Examples/Python/GeometricObjects/Display/Cube) >> >> >> >> What?s the best way to go about updating these to both support vtk 5 and >> support vtk 6+ >> >> >> >> Any preference about updating the wiki pages? Or maybe I am missing the >> location of the vtk6 python examples >> >> >> >> 1. Fix something in the current build system? >> >> 2. Create separate examples for vtk5 and vtk6 >> >> 3. Use if check (Seems like it could get messy) >> >> if VTK_MAJOR_VERSION <= 5: >> >> current vtk >> >> code else: >> >> vtk6+ code >> >> >> >> -Grant >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Dec 10 17:58:03 2014 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Dec 2014 17:58:03 -0500 Subject: [vtk-developers] AIX00F614-xlC has not been submitting since Nov 26, 2014 (14 days) Message-ID: <20141210225803.1702770009@mail.rogue-research.com> Hi all, Is AIX00F614-xlC kitware's? It hasn't submitted to VTK dashboard for 2 weeks. Can someone kick it? :) 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 wwthunan at gmail.com Thu Dec 11 09:36:44 2014 From: wwthunan at gmail.com (GeeKer Wang) Date: Thu, 11 Dec 2014 22:36:44 +0800 Subject: [vtk-developers] Fwd: Some bugs about vtkSphereWidget? In-Reply-To: References: Message-ID: When I checked the source code of vtkSphereWidget.cxx, vtkSphereWidget2.cxx and vtkSphereRepresentation.cxx in vtk6.1.0, I found following problems: 1. vtkSphereReprentation::SetHandlePosition() does not make the HandlePosition[3] updated 2. vtkSphereWidget2::TranslationEnabled/ScalingEnabled never used 3. vtkSphereWidget::SetHandleDirection() does not work before PlaceHandle() is called Are they bugs or just some kind of convention? -- Wentao Wang From brad.king at kitware.com Thu Dec 11 10:49:33 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Dec 2014 10:49:33 -0500 Subject: [vtk-developers] AIX00F614-xlC has not been submitting since Nov 26, 2014 (14 days) In-Reply-To: <20141210225803.1702770009@mail.rogue-research.com> References: <20141210225803.1702770009@mail.rogue-research.com> Message-ID: On Wed, Dec 10, 2014 at 5:58 PM, Sean McBride wrote: > Is AIX00F614-xlC kitware's? It hasn't submitted to VTK dashboard for 2 weeks. Can someone kick it? :) It was not our machine and we no longer have remote access to it. -Brad From dave.demarle at kitware.com Thu Dec 11 11:53:45 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Dec 2014 11:53:45 -0500 Subject: [vtk-developers] AIX00F614-xlC has not been submitting since Nov 26, 2014 (14 days) In-Reply-To: References: <20141210225803.1702770009@mail.rogue-research.com> Message-ID: AIX00F614-xlC is dead, long live urras. I've marked it as "not expected". Chuck has already put a bit of time into setting up urras.kitware to run a swath of compilers that are typically found on HPC systems. I'll promote its submissions to the nightly expected section. Thanks to friends at intel and pgi/intel we have intel and pgi installed there, as well as free compilers, all on the same platform. Still angling for access to a cray compiler, and ibm compilers (both xlc and bgxlc). I'm pretty sure I can set up one for cray coverage thanks to friends at Cray. If anyone has friends at IBM who can help get me access to their systems and tools for dashboard purposes, please let me know. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 11, 2014 at 10:49 AM, Brad King wrote: > On Wed, Dec 10, 2014 at 5:58 PM, Sean McBride > wrote: > > Is AIX00F614-xlC kitware's? It hasn't submitted to VTK dashboard for 2 > weeks. Can someone kick it? :) > > It was not our machine and we no longer have remote access to it. > > -Brad > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Dec 11 11:54:31 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Dec 2014 11:54:31 -0500 Subject: [vtk-developers] AIX00F614-xlC has not been submitting since Nov 26, 2014 (14 days) In-Reply-To: References: <20141210225803.1702770009@mail.rogue-research.com> Message-ID: Correction "pgi/intel" should have been "pgi/nvidia". David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 11, 2014 at 11:53 AM, David E DeMarle wrote: > AIX00F614-xlC is dead, long live urras. > > I've marked it as "not expected". > > Chuck has already put a bit of time into setting up urras.kitware to run a > swath of compilers that are typically found on HPC systems. I'll promote > its submissions to the nightly expected section. Thanks to friends at intel > and pgi/intel we have intel and pgi installed there, as well as free > compilers, all on the same platform. > > Still angling for access to a cray compiler, and ibm compilers (both xlc > and bgxlc). I'm pretty sure I can set up one for cray coverage thanks to > friends at Cray. If anyone has friends at IBM who can help get me access to > their systems and tools for dashboard purposes, please let me know. > > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Dec 11, 2014 at 10:49 AM, Brad King wrote: > >> On Wed, Dec 10, 2014 at 5:58 PM, Sean McBride >> wrote: >> > Is AIX00F614-xlC kitware's? It hasn't submitted to VTK dashboard for 2 >> weeks. Can someone kick it? :) >> >> It was not our machine and we no longer have remote access to it. >> >> -Brad >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Dec 11 11:54:44 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 11 Dec 2014 09:54:44 -0700 Subject: [vtk-developers] gerrit builds are down Message-ID: Hi all, Pushing to gerrit no longer triggers a dashboard build, it seems to have stopped working sometime last night. Could one of the Kitware folks investigate? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Dec 11 12:06:56 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 11 Dec 2014 12:06:56 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" Message-ID: Hi Folks, While developing 3D Slicer, we created a macro named vtkInfoMacro similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". We would like to contribute it back to VTK core. The associated topic is: http://review.source.kitware.com/#/c/18385/ It would be great to get feedback before moving forward. Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Dec 11 12:24:03 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Dec 2014 12:24:03 -0500 Subject: [vtk-developers] gerrit builds are down In-Reply-To: References: Message-ID: thanks looking into it David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 11, 2014 at 11:54 AM, David Gobbi wrote: > Hi all, > > Pushing to gerrit no longer triggers a dashboard build, it seems to have > stopped working sometime last night. Could one of the Kitware folks > investigate? > > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Dec 11 13:36:51 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 11 Dec 2014 13:36:51 -0500 Subject: [vtk-developers] AIX00F614-xlC has not been submitting since Nov 26, 2014 (14 days) In-Reply-To: References: <20141210225803.1702770009@mail.rogue-research.com> Message-ID: I can get IBM xlc on Power7+AIX via the GCC compile farm. - Chuck On Thu, Dec 11, 2014 at 11:54 AM, David E DeMarle wrote: > Correction "pgi/intel" should have been "pgi/nvidia". > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Dec 11, 2014 at 11:53 AM, David E DeMarle < > dave.demarle at kitware.com> wrote: > >> AIX00F614-xlC is dead, long live urras. >> >> I've marked it as "not expected". >> >> Chuck has already put a bit of time into setting up urras.kitware to run >> a swath of compilers that are typically found on HPC systems. I'll promote >> its submissions to the nightly expected section. Thanks to friends at intel >> and pgi/intel we have intel and pgi installed there, as well as free >> compilers, all on the same platform. >> >> Still angling for access to a cray compiler, and ibm compilers (both xlc >> and bgxlc). I'm pretty sure I can set up one for cray coverage thanks to >> friends at Cray. If anyone has friends at IBM who can help get me access to >> their systems and tools for dashboard purposes, please let me know. >> >> >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Thu, Dec 11, 2014 at 10:49 AM, Brad King >> wrote: >> >>> On Wed, Dec 10, 2014 at 5:58 PM, Sean McBride >>> wrote: >>> > Is AIX00F614-xlC kitware's? It hasn't submitted to VTK dashboard for >>> 2 weeks. Can someone kick it? :) >>> >>> It was not our machine and we no longer have remote access to it. >>> >>> -Brad >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Dec 11 16:45:01 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Dec 2014 16:45:01 -0500 Subject: [vtk-developers] gerrit builds are down In-Reply-To: References: Message-ID: Should be fixed now. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 11, 2014 at 12:24 PM, David E DeMarle wrote: > thanks > looking into it > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Dec 11, 2014 at 11:54 AM, David Gobbi > wrote: > >> Hi all, >> >> Pushing to gerrit no longer triggers a dashboard build, it seems to have >> stopped working sometime last night. Could one of the Kitware folks >> investigate? >> >> - David >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Dec 11 16:53:42 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 11 Dec 2014 16:53:42 -0500 Subject: [vtk-developers] Renaming ExternalData.cmake into VTKExternalData.cmake (was: Fwd: [slicer-devel] IASEM Module Build issue with ExternalData on Windows) Message-ID: Hi Folks, Similarly to what was done in ITK [1], would it be possible to rename the ExternalData module provided by VTK into "VTKExternalData.cmake" ? Doing so would ensure the module provided by CMake is always used. See below for more details. Thanks Jc [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/ITKExternalData.cmake ---------- Forwarded message ---------- From: Bradley Lowekamp Date: Mon, Dec 8, 2014 at 11:02 AM Subject: [slicer-devel] IASEM Module Build issue with ExternalData on Windows To: "slicer-devel at bwh.harvard.edu" Hello folk, I am hoping someone may recognize this issue. I am trying to address the error on windows due to data download[1]: 17>Generating /.../IASEM-build/IASEMImportSeries/Data/Input/InLens/slice_01529_z=5.0193um.tif 17>CMake Error at C:/D/N/Slicer-1-build/VTKv6/CMake/ExternalData.cmake:758 (message): 17> No "-Dfile=" value provided! 17>Project : error PRJ0019: A tool returned an error code from "Generating /.../IASEM-build/IASEMImportSeries/Data/Input/InLens/slice_01529_z=5.0193um.tif" In my IASEM extension, I am including the CMake "ExternalData" module to download some testing data[2]. However from the error message, it appears to be including VTK's "ExternalData.cmake" module and not the CMake's version. I presume this maybe related to why it work for the single file[3] and not the REGEX series[4]. Thanks for any help in getting my module to be packaged up for windows. Brad p.s. I make use of an environment variable "ExternalData_OBJECT_STORES" to store the ExternalData outside of the build directory. I know ITK and SimpleITK supports this. This makew the data stay locally between builds making it a rare occurrence for the data to actually be downloaded from the server. This improves the reliability and build times of regular testing. I don't think Slicer supports this nor the Slicer CDash build environment. It may be a good thing to do. [1] http://slicer.cdash.org/viewBuildError.php?buildid=320198 [2] https://github.com/blowekamp/Slicer-IASEM/blob/master/IASEMImportSeries/Testing/CMakeLists.txt#L2 [3] https://github.com/blowekamp/Slicer-IASEM/blob/master/IASEMImportSeries/Testing/CMakeLists.txt#L44 [4] https://github.com/blowekamp/Slicer-IASEM/blob/master/IASEMImportSeries/Testing/CMakeLists.txt#L48 _______________________________________________ slicer-devel mailing list slicer-devel at bwh.harvard.edu http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel To unsubscribe: send email to slicer-devel-request at bwh.harvard.edu with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Dec 11 17:36:50 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 11 Dec 2014 15:36:50 -0700 Subject: [vtk-developers] gerrit builds are down In-Reply-To: References: Message-ID: Thanks. On Thu, Dec 11, 2014 at 2:45 PM, David E DeMarle wrote: > Should be fixed now. > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Dec 11, 2014 at 12:24 PM, David E DeMarle < > dave.demarle at kitware.com> wrote: > >> thanks >> looking into it >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Thu, Dec 11, 2014 at 11:54 AM, David Gobbi >> wrote: >> >>> Hi all, >>> >>> Pushing to gerrit no longer triggers a dashboard build, it seems to have >>> stopped working sometime last night. Could one of the Kitware folks >>> investigate? >>> >>> - David >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Dec 12 08:27:30 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Dec 2014 08:27:30 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: I disagree with this change. There is no compelling VTK specific example for why this is needed. The examples are all from Slicer - which to me says that they can be implemented in Slicer. Adding a logging functionality without clear guidelines on how to use it is dangerous. It can lead to folks using it for debugging in performance critical sections and since it is not compiled out in Release builds, it can lead to significant performance issues, specially in multi-threaded code. As it is, there are lot of minor issues like this that we will have to go and clean up (progress being one of them). The main use case seems to be tracking interaction/workflow changes. My suggestion is to employ a method appropriate to that. For example, events and listeners. Best, -berk On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > > It would be great to get feedback before moving forward. > > Thanks > Jc > > > -- > +1 919 869 8849 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Dec 12 08:46:32 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Dec 2014 08:46:32 -0500 Subject: [vtk-developers] [vtkusers] Static Analysis of VTK In-Reply-To: References: Message-ID: +10 On Tue, Dec 9, 2014 at 3:03 PM, David E DeMarle wrote: > > +1 > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Dec 9, 2014 at 2:56 PM, Bill Lorensen > wrote: > >> +1 >> >> >> On Tue, Dec 9, 2014 at 2:49 PM, Andrew Maclean >> wrote: >> > Sean, >> > You are doing an awesome job cleaning up VTK! >> > I, for one, deeply appreciate what you are doing. >> > >> > Regards >> > Andrew >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://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 > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Dec 12 09:12:57 2014 From: david.lonie at kitware.com (David Lonie) Date: Fri, 12 Dec 2014 09:12:57 -0500 Subject: [vtk-developers] Gerrit and HDF5 woes Message-ID: Hi all, I've noticed that my gerrit builds will sometimes fail with errors in HDF5, eg: https://open.cdash.org/viewBuildError.php?buildid=3607808 Sometime it happens, sometimes it doesn't, sometimes it goes away, sometimes it comes back. Anyone know what's triggering these problems so I can avoid them? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Dec 12 09:16:12 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 12 Dec 2014 07:16:12 -0700 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: On the one hand, I can see that it is useful to have a message macro that doesn't require a debug build. In my own apps, I often write app-specific classes that are derived from vtkObject and this is a macro that I might use from time to time. Unlike Berk, I'm not all that worried that it might be abused. For VTK, we have code review. On the other hand, I don't think we have a use case for this within VTK itself, it would be there purely to serve external VTK classes and apps. And people who need this feature could simply put this macro (or a similar one) in their own header files. Summary: this is a convenience feature, IMHO a mostly harmless one, and one that I might use. - David On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci wrote: > I disagree with this change. There is no compelling VTK specific example > for why this is needed. The examples are all from Slicer - which to me says > that they can be implemented in Slicer. > > Adding a logging functionality without clear guidelines on how to use it > is dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it > can lead to significant performance issues, specially in multi-threaded > code. As it is, there are lot of minor issues like this that we will have > to go and clean up (progress being one of them). > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > Best, > -berk > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Hi Folks, >> >> While developing 3D Slicer, we created a macro named >> >> vtkInfoMacro >> >> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >> >> >> We would like to contribute it back to VTK core. >> >> >> >> The associated topic is: >> >> http://review.source.kitware.com/#/c/18385/ >> >> >> It would be great to get feedback before moving forward. >> >> Thanks >> Jc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Dec 12 09:32:35 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Dec 2014 09:32:35 -0500 Subject: [vtk-developers] Renaming ExternalData.cmake into VTKExternalData.cmake In-Reply-To: References: Message-ID: <548AFC83.6060706@kitware.com> On 12/11/2014 04:53 PM, Jean-Christophe Fillion-Robin wrote: > Similarly to what was done in ITK [1], would it be possible to > rename the ExternalData module provided by VTK into "VTKExternalData.cmake" ? The ITKExternalData.cmake file holds project-specific configuration information but ITK still has its own ExternalData.cmake file as well. A module called vtkExternalData already exists for the same purpose. ITK and VTK have their own ExternalData module because it backports fixes from versions of the module in CMake versions larger than what the projects specify in cmake_minimum_required(VERSION). Also they originally had their own copies prior to introduction of the module into CMake. > Doing so would ensure the module provided by CMake is always used. Yes, renaming the ExternalData modules in VTK and ITK would prevent conflicts when applications try to use the one from CMake. Currently vtkExternalData.cmake starts with: > get_filename_component(_VTKExternalData_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) > include(${_VTKExternalData_DIR}/ExternalData.cmake) No other code mentions the name "ExternalData" directly. One simply needs to rename the module file and update this include line. -Brad K From utkarsh.ayachit at kitware.com Fri Dec 12 09:34:52 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 12 Dec 2014 09:34:52 -0500 Subject: [vtk-developers] Gerrit and HDF5 woes In-Reply-To: References: Message-ID: Are you rebased on latest VTK/master? I suspect any branches that are not off master may cause the dashboard to enter a bad state because of HDF5 upgrade that hit VTK recently. Evendently, one has to do a clean build to avoid lingering cache variables from influencing the build. Ben, can you do a quick check to see if this easy to fix? I am guessing there're some stale variables being used in HDF5 cmake files? On Fri, Dec 12, 2014 at 9:12 AM, David Lonie wrote: > Hi all, > > I've noticed that my gerrit builds will sometimes fail with errors in HDF5, > eg: > > https://open.cdash.org/viewBuildError.php?buildid=3607808 > > Sometime it happens, sometimes it doesn't, sometimes it goes away, sometimes > it comes back. > > Anyone know what's triggering these problems so I can avoid them? > > Thanks, > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.lonie at kitware.com Fri Dec 12 09:36:11 2014 From: david.lonie at kitware.com (David Lonie) Date: Fri, 12 Dec 2014 09:36:11 -0500 Subject: [vtk-developers] Gerrit and HDF5 woes In-Reply-To: References: Message-ID: It's based off of pvmaster, so it might be a bit out of date. On Fri, Dec 12, 2014 at 9:34 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > > Are you rebased on latest VTK/master? I suspect any branches that are > not off master may cause the dashboard to enter a bad state because of > HDF5 upgrade that hit VTK recently. Evendently, one has to do a clean > build to avoid lingering cache variables from influencing the build. > Ben, can you do a quick check to see if this easy to fix? I am > guessing there're some stale variables being used in HDF5 cmake files? > > On Fri, Dec 12, 2014 at 9:12 AM, David Lonie > wrote: > > Hi all, > > > > I've noticed that my gerrit builds will sometimes fail with errors in > HDF5, > > eg: > > > > https://open.cdash.org/viewBuildError.php?buildid=3607808 > > > > Sometime it happens, sometimes it doesn't, sometimes it goes away, > sometimes > > it comes back. > > > > Anyone know what's triggering these problems so I can avoid them? > > > > Thanks, > > Dave > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Dec 12 09:52:50 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 12 Dec 2014 07:52:50 -0700 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: However, I have reservations about putting this macro in vtkSetGet.h. If it goes in its own header, then the chances of it being confused with vtkDebugMacro are significantly reduced. - David On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > I completely agree with David. This is an application support feature. > There are several examples for such features in VTK, including QVTKWidget > or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK > library itself (other than examples and tests) but in VTK-based > applications. They make the life of application developers easier, allow > standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help application > developers. > > > > Andras > > > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com] > *Sent:* Friday, December 12, 2014 09:16 > *To:* vtk-developers at vtk.org > *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro that > doesn't require a debug build. In my own apps, I often write app-specific > classes that are derived from vtkObject and this is a macro that I might > use from time to time. Unlike Berk, I'm not all that worried that it might > be abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within VTK > itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, and > one that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific example > for why this is needed. The examples are all from Slicer - which to me says > that they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use it > is dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it > can lead to significant performance issues, specially in multi-threaded > code. As it is, there are lot of minor issues like this that we will have > to go and clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Dec 12 11:44:09 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 12 Dec 2014 09:44:09 -0700 Subject: [vtk-developers] TestGDALRasterReader In-Reply-To: References: Message-ID: Hi Aashish, Just a reminder, the GDAL reader test failures are still showing up on the dashboard. - David On Tue, Dec 9, 2014 at 3:18 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > > David, > > Will push a fix. Didn't that one of the dashboard was building and using > the GDAL. I am on travel today but will try to push a fix tomorrow. > > Thanks, > > > On Tue, Dec 9, 2014 at 10:54 AM, David Gobbi > wrote: > >> The test for vtkGDALRasterReader has been failing ever since it was >> merged. It also shows memory leaks with valgrind: >> http://open.cdash.org/viewDynamicAnalysisFile.php?id=3325863 >> >> It looks like its input data is missing. >> >> - David >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Dec 12 13:07:51 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 12 Dec 2014 13:07:51 -0500 Subject: [vtk-developers] TestGDALRasterReader In-Reply-To: References: Message-ID: David, I pushed a simple fix and that should fix the failure (Added you as the reviewer). I will look into some other possible issues (like memory leak). Thanks, On Fri, Dec 12, 2014 at 11:44 AM, David Gobbi wrote: > > Hi Aashish, > > Just a reminder, the GDAL reader test failures are still showing up on the > dashboard. > > - David > > On Tue, Dec 9, 2014 at 3:18 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: >> >> David, >> >> Will push a fix. Didn't that one of the dashboard was building and using >> the GDAL. I am on travel today but will try to push a fix tomorrow. >> >> Thanks, >> >> >> On Tue, Dec 9, 2014 at 10:54 AM, David Gobbi >> wrote: >> >>> The test for vtkGDALRasterReader has been failing ever since it was >>> merged. It also shows memory leaks with valgrind: >>> http://open.cdash.org/viewDynamicAnalysisFile.php?id=3325863 >>> >>> It looks like its input data is missing. >>> >>> - David >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Dec 12 14:14:06 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 12 Dec 2014 12:14:06 -0700 Subject: [vtk-developers] TestGDALRasterReader In-Reply-To: References: Message-ID: Thanks. I see that I was a little late to review :) - David On Fri, Dec 12, 2014 at 11:07 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > > David, > > I pushed a simple fix and that should fix the failure (Added you as the > reviewer). I will look into some other possible issues (like memory leak). > > Thanks, > > > > On Fri, Dec 12, 2014 at 11:44 AM, David Gobbi > wrote: >> >> Hi Aashish, >> >> Just a reminder, the GDAL reader test failures are still showing up on >> the dashboard. >> >> - David >> >> On Tue, Dec 9, 2014 at 3:18 PM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >>> >>> David, >>> >>> Will push a fix. Didn't that one of the dashboard was building and using >>> the GDAL. I am on travel today but will try to push a fix tomorrow. >>> >>> Thanks, >>> >>> >>> On Tue, Dec 9, 2014 at 10:54 AM, David Gobbi >>> wrote: >>> >>>> The test for vtkGDALRasterReader has been failing ever since it was >>>> merged. It also shows memory leaks with valgrind: >>>> http://open.cdash.org/viewDynamicAnalysisFile.php?id=3325863 >>>> >>>> It looks like its input data is missing. >>>> >>>> - David >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Fri Dec 12 17:35:11 2014 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 12 Dec 2014 17:35:11 -0500 Subject: [vtk-developers] Scalar coloring modes and polygonal rendering Message-ID: Hi all, We have completed the implementation of a new mode for mapping scalars to colors for vtkPolyDataMapper (and related classes): VTK_COLOR_MODE_DIRECT_SCALARS. If VTK_COLOR_MODE_DIRECT_SCALARS is set, then all arrays types are treated as colors (integer types are clamped in the range 0-255, floating point arrays are clamped in the range 0.0-1.0). Contrast this mode with the traditional VTK modes: VTK_COLOR_MODE_DEFAULT: only unsigned char data arrays are treated as colors (and converted to RGBA if necessary) all other types are mapped the the color map VTK_COLOR_MODE_MAP_SCALARS: all arrays are mapped through the color map. See http://review.source.kitware.com/#/t/5022/ For details of the implementation and classes affected. Dan ---------- Forwarded message ---------- From: Utkarsh Ayachit Date: Wed, Nov 12, 2014 at 12:42 PM Subject: Scalar coloring modes and polygonal rendering To: "vtk-developers at vtk.org" Folks, vtkPolyDataMapper since a long time supports two coloring modes, viz. VTK_COLOR_MODE_DEFAULT and VTK_COLOR_MODE_MAP_SCALARS. MapScalars indicates always use a vtkScalarsToColors instance to map data values to colors. Default means only use the vtkScalarsToColors if the data array is not an unsigned char array. I am working on a feature request [1] to add support to not use a vtkScalarsToColors instance for non-unsigned-char arrays (including double/float), assuming they are in the range 0, 1. To support this mode without breaking current behavior, I am thinking of adding a new VTK_COLOR_MODE_NO_MAP_SCALARS mode which can be used to force interpreting the data values as colors directly. Any objections to that? Also if any suggestions for the name for this new mode are highly welcome. Thanks Utkarsh [1] http://www.paraview.org/Bug/view.php?id=14943 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Dec 12 19:12:20 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Dec 2014 19:12:20 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: I'd be fine with it if the header is put into a higher level module such as GUISupport and has some examples demonstrating its purpose and some documentation providing a guide on how to use it. I would not agree to putting this at a place where it may encourage folks to use it in algorithms and other core functionality. As I mentioned previously, I already have the unpleasant job of ripping out a number of "convenience" functionality that are going to have significant impact on performance as we continue to multi-thread more algorithms. All of these features look harmless when initially added. Then they find their way into core functionality slowly but surely. When you are considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. Some simple examples: * Garbage collection * vtkDataArrayTemplate::DataChanged() * Abundant use of Modified() * Progress reporting Very nice and convenient feature. They may lead to a code running more slowly as more threads are added rather than scale up. I don't agree that misuse of such features would get caught in reviews. Very few reviewers are conscious of potential performance issues. Because very few developers are performance conscious at this point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). So this is not the time to pepper core classes with convenience functionality. It is time to simplify and come with very clear guidelines on what core classes and algorithms can and cannot do. Once the development community becomes more aware of these issues and our dashboards are able to catch performance regressions, we can relax some. Best, -berk On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. If > it goes in its own header, then the chances of it being confused with > vtkDebugMacro are significantly reduced. > > - David > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > >> I completely agree with David. This is an application support feature. >> There are several examples for such features in VTK, including QVTKWidget >> or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK >> library itself (other than examples and tests) but in VTK-based >> applications. They make the life of application developers easier, allow >> standardization, reduces code/feature duplication. >> >> >> >> Adding the macro has negligible impact on VTK but would help application >> developers. >> >> >> >> Andras >> >> >> >> >> >> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >> *Sent:* Friday, December 12, 2014 09:16 >> *To:* vtk-developers at vtk.org >> *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso >> *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" >> >> >> >> On the one hand, I can see that it is useful to have a message macro that >> doesn't require a debug build. In my own apps, I often write app-specific >> classes that are derived from vtkObject and this is a macro that I might >> use from time to time. Unlike Berk, I'm not all that worried that it might >> be abused. For VTK, we have code review. >> >> >> >> On the other hand, I don't think we have a use case for this within VTK >> itself, it would be there purely to serve external VTK classes and apps. >> And people who need this feature could simply put this macro (or a similar >> one) in their own header files. >> >> >> >> Summary: this is a convenience feature, IMHO a mostly harmless one, and >> one that I might use. >> >> >> >> - David >> >> >> >> >> >> On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci >> wrote: >> >> I disagree with this change. There is no compelling VTK specific >> example for why this is needed. The examples are all from Slicer - which to >> me says that they can be implemented in Slicer. >> >> >> >> Adding a logging functionality without clear guidelines on how to use it >> is dangerous. It can lead to folks using it for debugging in performance >> critical sections and since it is not compiled out in Release builds, it >> can lead to significant performance issues, specially in multi-threaded >> code. As it is, there are lot of minor issues like this that we will have >> to go and clean up (progress being one of them). >> >> >> >> The main use case seems to be tracking interaction/workflow changes. My >> suggestion is to employ a method appropriate to that. For example, events >> and listeners. >> >> >> >> Best, >> >> -berk >> >> >> >> >> >> On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >> Hi Folks, >> >> While developing 3D Slicer, we created a macro named >> >> vtkInfoMacro >> >> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >> >> We would like to contribute it back to VTK core. >> >> >> >> The associated topic is: >> >> http://review.source.kitware.com/#/c/18385/ >> >> It would be great to get feedback before moving forward. >> >> Thanks >> >> Jc >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Dec 12 21:54:20 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 12 Dec 2014 19:54:20 -0700 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Well, vtkImageReslice is probably not the best "speed" example any more, it has become fat with all the features that I've added to it over the years :) And in the old days, a big reason for its speed was that it did some bit-twiddling to work around the disastrously slow floor() operations on old CPUs. However, it is certainly true with modern computer architectures, with their multiple cores and fast caches, doing _any_ application-level or system-level operations within the algorithmic code causes a significant performance hit, because that takes the CPU core out of the "zone" where it can work at its full potential. - David On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci wrote: > > I'd be fine with it if the header is put into a higher level module such > as GUISupport and has some examples demonstrating its purpose and some > documentation providing a guide on how to use it. I would not agree to > putting this at a place where it may encourage folks to use it in > algorithms and other core functionality. As I mentioned previously, I > already have the unpleasant job of ripping out a number of "convenience" > functionality that are going to have significant impact on performance as > we continue to multi-thread more algorithms. All of these features look > harmless when initially added. Then they find their way into core > functionality slowly but surely. When you are considering 200-way > parallelism (which we are, since we are porting to Intel Xeon Phi already), > any little bit makes a difference. Some simple examples: > > * Garbage collection > * vtkDataArrayTemplate::DataChanged() > * Abundant use of Modified() > * Progress reporting > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > I don't agree that misuse of such features would get caught in reviews. > Very few reviewers are conscious of potential performance issues. Because > very few developers are performance conscious at this point (Dave Gobbi > excepted, he writes amazingly fast code, see image reslice). > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear guidelines > on what core classes and algorithms can and cannot do. Once the development > community becomes more aware of these issues and our dashboards are able to > catch performance regressions, we can relax some. > > Best, > -berk > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: >> >> However, I have reservations about putting this macro in vtkSetGet.h. If >> it goes in its own header, then the chances of it being confused with >> vtkDebugMacro are significantly reduced. >> >> - David >> >> >> On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: >> >>> I completely agree with David. This is an application support feature. >>> There are several examples for such features in VTK, including QVTKWidget >>> or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK >>> library itself (other than examples and tests) but in VTK-based >>> applications. They make the life of application developers easier, allow >>> standardization, reduces code/feature duplication. >>> >>> >>> >>> Adding the macro has negligible impact on VTK but would help application >>> developers. >>> >>> >>> >>> Andras >>> >>> >>> >>> >>> >>> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >>> *Sent:* Friday, December 12, 2014 09:16 >>> *To:* vtk-developers at vtk.org >>> *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso >>> *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" >>> >>> >>> >>> On the one hand, I can see that it is useful to have a message macro >>> that doesn't require a debug build. In my own apps, I often write >>> app-specific classes that are derived from vtkObject and this is a macro >>> that I might use from time to time. Unlike Berk, I'm not all that worried >>> that it might be abused. For VTK, we have code review. >>> >>> >>> >>> On the other hand, I don't think we have a use case for this within VTK >>> itself, it would be there purely to serve external VTK classes and apps. >>> And people who need this feature could simply put this macro (or a similar >>> one) in their own header files. >>> >>> >>> >>> Summary: this is a convenience feature, IMHO a mostly harmless one, and >>> one that I might use. >>> >>> >>> >>> - David >>> >>> >>> >>> >>> >>> On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci >>> wrote: >>> >>> I disagree with this change. There is no compelling VTK specific >>> example for why this is needed. The examples are all from Slicer - which to >>> me says that they can be implemented in Slicer. >>> >>> >>> >>> Adding a logging functionality without clear guidelines on how to use it >>> is dangerous. It can lead to folks using it for debugging in performance >>> critical sections and since it is not compiled out in Release builds, it >>> can lead to significant performance issues, specially in multi-threaded >>> code. As it is, there are lot of minor issues like this that we will have >>> to go and clean up (progress being one of them). >>> >>> >>> >>> The main use case seems to be tracking interaction/workflow changes. My >>> suggestion is to employ a method appropriate to that. For example, events >>> and listeners. >>> >>> >>> >>> Best, >>> >>> -berk >>> >>> >>> >>> >>> >>> On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < >>> jchris.fillionr at kitware.com> wrote: >>> >>> Hi Folks, >>> >>> While developing 3D Slicer, we created a macro named >>> >>> vtkInfoMacro >>> >>> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >>> >>> We would like to contribute it back to VTK core. >>> >>> >>> >>> The associated topic is: >>> >>> http://review.source.kitware.com/#/c/18385/ >>> >>> It would be great to get feedback before moving forward. >>> >>> Thanks >>> >>> Jc >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Dec 13 09:27:35 2014 From: DLRdave at aol.com (David Cole) Date: Sat, 13 Dec 2014 09:27:35 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: I agree with Berk. VTK should NOT include the kitchen sink... This belongs elsewhere -- there are whole separate libraries that are actually focused on logging, and doing it in a high performance, high functionality manner. log4cpp, g2log, and boost all come to mind. Great to hear talk of testing performance regressions on the dashboard -- looking forward to the day that's a reality. Thx, David C. On Friday, December 12, 2014, David Gobbi wrote: > Well, vtkImageReslice is probably not the best "speed" example any more, > it has become fat with all the features that I've added to it over the > years :) And in the old days, a big reason for its speed was that it did > some bit-twiddling to work around the disastrously slow floor() operations > on old CPUs. > > However, it is certainly true with modern computer architectures, with > their multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a significant > performance hit, because that takes the CPU core out of the "zone" where it > can work at its full potential. > > - David > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: >> >> I'd be fine with it if the header is put into a higher level module such >> as GUISupport and has some examples demonstrating its purpose and some >> documentation providing a guide on how to use it. I would not agree to >> putting this at a place where it may encourage folks to use it in >> algorithms and other core functionality. As I mentioned previously, I >> already have the unpleasant job of ripping out a number of "convenience" >> functionality that are going to have significant impact on performance as >> we continue to multi-thread more algorithms. All of these features look >> harmless when initially added. Then they find their way into core >> functionality slowly but surely. When you are considering 200-way >> parallelism (which we are, since we are porting to Intel Xeon Phi already), >> any little bit makes a difference. Some simple examples: >> >> * Garbage collection >> * vtkDataArrayTemplate::DataChanged() >> * Abundant use of Modified() >> * Progress reporting >> >> Very nice and convenient feature. They may lead to a code running more >> slowly as more threads are added rather than scale up. >> >> I don't agree that misuse of such features would get caught in reviews. >> Very few reviewers are conscious of potential performance issues. Because >> very few developers are performance conscious at this point (Dave Gobbi >> excepted, he writes amazingly fast code, see image reslice). >> >> So this is not the time to pepper core classes with convenience >> functionality. It is time to simplify and come with very clear guidelines >> on what core classes and algorithms can and cannot do. Once the development >> community becomes more aware of these issues and our dashboards are able to >> catch performance regressions, we can relax some. >> >> Best, >> -berk >> >> >> >> >> On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > > wrote: >>> >>> However, I have reservations about putting this macro in vtkSetGet.h. If >>> it goes in its own header, then the chances of it being confused with >>> vtkDebugMacro are significantly reduced. >>> >>> - David >>> >>> >>> On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso >> > wrote: >>> >>>> I completely agree with David. This is an application support >>>> feature. There are several examples for such features in VTK, including >>>> QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to be >>>> used in VTK library itself (other than examples and tests) but in VTK-based >>>> applications. They make the life of application developers easier, allow >>>> standardization, reduces code/feature duplication. >>>> >>>> >>>> >>>> Adding the macro has negligible impact on VTK but would help >>>> application developers. >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> >>>> >>>> *From:* David Gobbi [mailto:david.gobbi at gmail.com >>>> ] >>>> *Sent:* Friday, December 12, 2014 09:16 >>>> *To:* vtk-developers at vtk.org >>>> >>>> *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso >>>> *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" >>>> >>>> >>>> >>>> On the one hand, I can see that it is useful to have a message macro >>>> that doesn't require a debug build. In my own apps, I often write >>>> app-specific classes that are derived from vtkObject and this is a macro >>>> that I might use from time to time. Unlike Berk, I'm not all that worried >>>> that it might be abused. For VTK, we have code review. >>>> >>>> >>>> >>>> On the other hand, I don't think we have a use case for this within VTK >>>> itself, it would be there purely to serve external VTK classes and apps. >>>> And people who need this feature could simply put this macro (or a similar >>>> one) in their own header files. >>>> >>>> >>>> >>>> Summary: this is a convenience feature, IMHO a mostly harmless one, and >>>> one that I might use. >>>> >>>> >>>> >>>> - David >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci >>> > wrote: >>>> >>>> I disagree with this change. There is no compelling VTK specific >>>> example for why this is needed. The examples are all from Slicer - which to >>>> me says that they can be implemented in Slicer. >>>> >>>> >>>> >>>> Adding a logging functionality without clear guidelines on how to use >>>> it is dangerous. It can lead to folks using it for debugging in performance >>>> critical sections and since it is not compiled out in Release builds, it >>>> can lead to significant performance issues, specially in multi-threaded >>>> code. As it is, there are lot of minor issues like this that we will have >>>> to go and clean up (progress being one of them). >>>> >>>> >>>> >>>> The main use case seems to be tracking interaction/workflow changes. My >>>> suggestion is to employ a method appropriate to that. For example, events >>>> and listeners. >>>> >>>> >>>> >>>> Best, >>>> >>>> -berk >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < >>>> jchris.fillionr at kitware.com >>>> > wrote: >>>> >>>> Hi Folks, >>>> >>>> While developing 3D Slicer, we created a macro named >>>> >>>> vtkInfoMacro >>>> >>>> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >>>> >>>> We would like to contribute it back to VTK core. >>>> >>>> >>>> >>>> The associated topic is: >>>> >>>> http://review.source.kitware.com/#/c/18385/ >>>> >>>> It would be great to get feedback before moving forward. >>>> >>>> Thanks >>>> >>>> Jc >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Sat Dec 13 11:35:36 2014 From: lasso at queensu.ca (Andras Lasso) Date: Sat, 13 Dec 2014 16:35:36 +0000 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Yes, sure we don?t need VTK to include a complete logging framework such as log4cpp. We just need a convenient mechanism to send messages to logging frameworks from VTK. What do you think about the following? * Allow completely disable vtkInfoMacro by an #ifdef (for example, if #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can set VTK_INFO_ENABLED to false by default) * Put the macro in a separate header in Common/vtkInfo.h to not make the macro visible to VTK classes by default. GUISupport directory would be too restrictive, as logging is not related to GUI and there are other application-only functions in Common already (such as vtkOutputWindow::DisplayText), but any other suggestion is welcome. Andras From: David Cole [mailto:DLRdave at aol.com] Sent: Saturday, December 13, 2014 09:28 To: David Gobbi Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" I agree with Berk. VTK should NOT include the kitchen sink... This belongs elsewhere -- there are whole separate libraries that are actually focused on logging, and doing it in a high performance, high functionality manner. log4cpp, g2log, and boost all come to mind. Great to hear talk of testing performance regressions on the dashboard -- looking forward to the day that's a reality. Thx, David C. On Friday, December 12, 2014, David Gobbi > wrote: Well, vtkImageReslice is probably not the best "speed" example any more, it has become fat with all the features that I've added to it over the years :) And in the old days, a big reason for its speed was that it did some bit-twiddling to work around the disastrously slow floor() operations on old CPUs. However, it is certainly true with modern computer architectures, with their multiple cores and fast caches, doing _any_ application-level or system-level operations within the algorithmic code causes a significant performance hit, because that takes the CPU core out of the "zone" where it can work at its full potential. - David On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: I'd be fine with it if the header is put into a higher level module such as GUISupport and has some examples demonstrating its purpose and some documentation providing a guide on how to use it. I would not agree to putting this at a place where it may encourage folks to use it in algorithms and other core functionality. As I mentioned previously, I already have the unpleasant job of ripping out a number of "convenience" functionality that are going to have significant impact on performance as we continue to multi-thread more algorithms. All of these features look harmless when initially added. Then they find their way into core functionality slowly but surely. When you are considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. Some simple examples: * Garbage collection * vtkDataArrayTemplate::DataChanged() * Abundant use of Modified() * Progress reporting Very nice and convenient feature. They may lead to a code running more slowly as more threads are added rather than scale up. I don't agree that misuse of such features would get caught in reviews. Very few reviewers are conscious of potential performance issues. Because very few developers are performance conscious at this point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). So this is not the time to pepper core classes with convenience functionality. It is time to simplify and come with very clear guidelines on what core classes and algorithms can and cannot do. Once the development community becomes more aware of these issues and our dashboards are able to catch performance regressions, we can relax some. Best, -berk On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: However, I have reservations about putting this macro in vtkSetGet.h. If it goes in its own header, then the chances of it being confused with vtkDebugMacro are significantly reduced. - David On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso > wrote: I completely agree with David. This is an application support feature. There are several examples for such features in VTK, including QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK library itself (other than examples and tests) but in VTK-based applications. They make the life of application developers easier, allow standardization, reduces code/feature duplication. Adding the macro has negligible impact on VTK but would help application developers. Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, December 12, 2014 09:16 To: vtk-developers at vtk.org Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" On the one hand, I can see that it is useful to have a message macro that doesn't require a debug build. In my own apps, I often write app-specific classes that are derived from vtkObject and this is a macro that I might use from time to time. Unlike Berk, I'm not all that worried that it might be abused. For VTK, we have code review. On the other hand, I don't think we have a use case for this within VTK itself, it would be there purely to serve external VTK classes and apps. And people who need this feature could simply put this macro (or a similar one) in their own header files. Summary: this is a convenience feature, IMHO a mostly harmless one, and one that I might use. - David On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: I disagree with this change. There is no compelling VTK specific example for why this is needed. The examples are all from Slicer - which to me says that they can be implemented in Slicer. Adding a logging functionality without clear guidelines on how to use it is dangerous. It can lead to folks using it for debugging in performance critical sections and since it is not compiled out in Release builds, it can lead to significant performance issues, specially in multi-threaded code. As it is, there are lot of minor issues like this that we will have to go and clean up (progress being one of them). The main use case seems to be tracking interaction/workflow changes. My suggestion is to employ a method appropriate to that. For example, events and listeners. Best, -berk On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin > wrote: Hi Folks, While developing 3D Slicer, we created a macro named vtkInfoMacro similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". We would like to contribute it back to VTK core. The associated topic is: http://review.source.kitware.com/#/c/18385/ It would be great to get feedback before moving forward. Thanks Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Dec 13 13:46:51 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 13 Dec 2014 13:46:51 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: ITK has a logger, itk::Logger. On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: > Yes, sure we don?t need VTK to include a complete logging framework such as > log4cpp. We just need a convenient mechanism to send messages to logging > frameworks from VTK. > > > > What do you think about the following? > > > > * Allow completely disable vtkInfoMacro by an #ifdef (for example, if > #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can set > VTK_INFO_ENABLED to false by default) > > > > * Put the macro in a separate header in Common/vtkInfo.h to not make the > macro visible to VTK classes by default. GUISupport directory would be too > restrictive, as logging is not related to GUI and there are other > application-only functions in Common already (such as > vtkOutputWindow::DisplayText), but any other suggestion is welcome. > > > > Andras > > > > From: David Cole [mailto:DLRdave at aol.com] > Sent: Saturday, December 13, 2014 09:28 > To: David Gobbi > Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso > > > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I agree with Berk. VTK should NOT include the kitchen sink... This belongs > elsewhere -- there are whole separate libraries that are actually focused on > logging, and doing it in a high performance, high functionality manner. > log4cpp, g2log, and boost all come to mind. > > Great to hear talk of testing performance regressions on the dashboard -- > looking forward to the day that's a reality. > > > > Thx, > > David C. > > > > > On Friday, December 12, 2014, David Gobbi wrote: > > Well, vtkImageReslice is probably not the best "speed" example any more, it > has become fat with all the features that I've added to it over the years :) > And in the old days, a big reason for its speed was that it did some > bit-twiddling to work around the disastrously slow floor() operations on old > CPUs. > > > > However, it is certainly true with modern computer architectures, with their > multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a significant > performance hit, because that takes the CPU core out of the "zone" where it > can work at its full potential. > > > > - David > > > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: > > I'd be fine with it if the header is put into a higher level module such as > GUISupport and has some examples demonstrating its purpose and some > documentation providing a guide on how to use it. I would not agree to > putting this at a place where it may encourage folks to use it in algorithms > and other core functionality. As I mentioned previously, I already have the > unpleasant job of ripping out a number of "convenience" functionality that > are going to have significant impact on performance as we continue to > multi-thread more algorithms. All of these features look harmless when > initially added. Then they find their way into core functionality slowly but > surely. When you are considering 200-way parallelism (which we are, since we > are porting to Intel Xeon Phi already), any little bit makes a difference. > Some simple examples: > > > > * Garbage collection > > * vtkDataArrayTemplate::DataChanged() > > * Abundant use of Modified() > > * Progress reporting > > > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > > > I don't agree that misuse of such features would get caught in reviews. Very > few reviewers are conscious of potential performance issues. Because very > few developers are performance conscious at this point (Dave Gobbi excepted, > he writes amazingly fast code, see image reslice). > > > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear guidelines on > what core classes and algorithms can and cannot do. Once the development > community becomes more aware of these issues and our dashboards are able to > catch performance regressions, we can relax some. > > > > Best, > > -berk > > > > > > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. If it > goes in its own header, then the chances of it being confused with > vtkDebugMacro are significantly reduced. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > > I completely agree with David. This is an application support feature. There > are several examples for such features in VTK, including QVTKWidget or > vtkOutputWindow::DisplayText(). These are not meant to be used in VTK > library itself (other than examples and tests) but in VTK-based > applications. They make the life of application developers easier, allow > standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help application > developers. > > > > Andras > > > > > > From: David Gobbi [mailto:david.gobbi at gmail.com] > Sent: Friday, December 12, 2014 09:16 > To: vtk-developers at vtk.org > Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro that > doesn't require a debug build. In my own apps, I often write app-specific > classes that are derived from vtkObject and this is a macro that I might use > from time to time. Unlike Berk, I'm not all that worried that it might be > abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within VTK > itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, and one > that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific example for > why this is needed. The examples are all from Slicer - which to me says that > they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use it is > dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it can > lead to significant performance issues, specially in multi-threaded code. As > it is, there are lot of minor issues like this that we will have to go and > clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin > wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From lasso at queensu.ca Sat Dec 13 14:54:49 2014 From: lasso at queensu.ca (Andras Lasso) Date: Sat, 13 Dec 2014 19:54:49 +0000 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Thanks for the pointer, Bill. The logger in ITK is quite nice and the info level logging macro is available in ITK: if the output window is set to itkLoggerOutput then itkGenericOutputMacro calls this->m_Logger->Write(LoggerBase::INFO, t) I don't think that adding an ITK-like logger to VTK is necessary, just adding the missing vtkInfo (or vtkGenericOutput) macro would be enough. Andras -----Original Message----- From: Bill Lorensen [mailto:bill.lorensen at gmail.com] Sent: Saturday, December 13, 2014 13:47 To: Andras Lasso Cc: David Cole; David Gobbi; vtk-developers at vtk.org; Berk Geveci Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" ITK has a logger, itk::Logger. On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: > Yes, sure we don?t need VTK to include a complete logging framework > such as log4cpp. We just need a convenient mechanism to send messages > to logging frameworks from VTK. > > > > What do you think about the following? > > > > * Allow completely disable vtkInfoMacro by an #ifdef (for example, if > #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we > can set VTK_INFO_ENABLED to false by default) > > > > * Put the macro in a separate header in Common/vtkInfo.h to not make > the macro visible to VTK classes by default. GUISupport directory > would be too restrictive, as logging is not related to GUI and there > are other application-only functions in Common already (such as > vtkOutputWindow::DisplayText), but any other suggestion is welcome. > > > > Andras > > > > From: David Cole [mailto:DLRdave at aol.com] > Sent: Saturday, December 13, 2014 09:28 > To: David Gobbi > Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso > > > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I agree with Berk. VTK should NOT include the kitchen sink... This > belongs elsewhere -- there are whole separate libraries that are > actually focused on logging, and doing it in a high performance, high functionality manner. > log4cpp, g2log, and boost all come to mind. > > Great to hear talk of testing performance regressions on the dashboard > -- looking forward to the day that's a reality. > > > > Thx, > > David C. > > > > > On Friday, December 12, 2014, David Gobbi wrote: > > Well, vtkImageReslice is probably not the best "speed" example any > more, it has become fat with all the features that I've added to it > over the years :) And in the old days, a big reason for its speed was > that it did some bit-twiddling to work around the disastrously slow > floor() operations on old CPUs. > > > > However, it is certainly true with modern computer architectures, with > their multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a > significant performance hit, because that takes the CPU core out of > the "zone" where it can work at its full potential. > > > > - David > > > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: > > I'd be fine with it if the header is put into a higher level module > such as GUISupport and has some examples demonstrating its purpose and > some documentation providing a guide on how to use it. I would not > agree to putting this at a place where it may encourage folks to use > it in algorithms and other core functionality. As I mentioned > previously, I already have the unpleasant job of ripping out a number > of "convenience" functionality that are going to have significant > impact on performance as we continue to multi-thread more algorithms. > All of these features look harmless when initially added. Then they > find their way into core functionality slowly but surely. When you are > considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. > Some simple examples: > > > > * Garbage collection > > * vtkDataArrayTemplate::DataChanged() > > * Abundant use of Modified() > > * Progress reporting > > > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > > > I don't agree that misuse of such features would get caught in > reviews. Very few reviewers are conscious of potential performance > issues. Because very few developers are performance conscious at this > point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). > > > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear > guidelines on what core classes and algorithms can and cannot do. Once > the development community becomes more aware of these issues and our > dashboards are able to catch performance regressions, we can relax some. > > > > Best, > > -berk > > > > > > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. > If it goes in its own header, then the chances of it being confused > with vtkDebugMacro are significantly reduced. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > > I completely agree with David. This is an application support feature. > There are several examples for such features in VTK, including > QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to > be used in VTK library itself (other than examples and tests) but in > VTK-based applications. They make the life of application developers > easier, allow standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help > application developers. > > > > Andras > > > > > > From: David Gobbi [mailto:david.gobbi at gmail.com] > Sent: Friday, December 12, 2014 09:16 > To: vtk-developers at vtk.org > Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro > that doesn't require a debug build. In my own apps, I often write > app-specific classes that are derived from vtkObject and this is a > macro that I might use from time to time. Unlike Berk, I'm not all > that worried that it might be abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within > VTK itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a > similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, > and one that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific > example for why this is needed. The examples are all from Slicer - > which to me says that they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use > it is dangerous. It can lead to folks using it for debugging in > performance critical sections and since it is not compiled out in > Release builds, it can lead to significant performance issues, > specially in multi-threaded code. As it is, there are lot of minor > issues like this that we will have to go and clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. > My suggestion is to employ a method appropriate to that. For example, > events and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin > wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Sat Dec 13 15:15:41 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 13 Dec 2014 15:15:41 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Sorry but I remain unconvinced. I haven't heard a compelling reason why this functionality should be available to core VTK modules and why the maintainers of those modules need to worry about it. So far, the only example is for a class in Slicer. Whether this is in a separate header or not, putting it in Common/Core will make it possible for all modules in VTK to use this functionality without any compile errors. As I mentioned, I'd like to see functionality migrate out of Common/Core to outer modules not vice versa. "There are other application-only functions in Common already" is not a good reason why we should cram more in there. Also, vtkOutputWindow is used for VTK-level functionality such as debugging and error reporting. Similar to vtkDebugLeaks. I wouldn't call that application specific. Best, -berk On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: > > Yes, sure we don?t need VTK to include a complete logging framework such > as log4cpp. We just need a convenient mechanism to send messages to logging > frameworks from VTK. > > > > What do you think about the following? > > > > * Allow completely disable vtkInfoMacro by an #ifdef (for example, if > #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can > set VTK_INFO_ENABLED to false by default) > > > > * Put the macro in a separate header in Common/vtkInfo.h to not make the > macro visible to VTK classes by default. GUISupport directory would be too > restrictive, as logging is not related to GUI and there are other > application-only functions in Common already (such as > vtkOutputWindow::DisplayText), but any other suggestion is welcome. > > > > Andras > > > > *From:* David Cole [mailto:DLRdave at aol.com] > *Sent:* Saturday, December 13, 2014 09:28 > *To:* David Gobbi > *Cc:* Berk Geveci; vtk-developers at vtk.org; Andras Lasso > > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I agree with Berk. VTK should NOT include the kitchen sink... This belongs > elsewhere -- there are whole separate libraries that are actually focused > on logging, and doing it in a high performance, high functionality manner. > log4cpp, g2log, and boost all come to mind. > > Great to hear talk of testing performance regressions on the dashboard -- > looking forward to the day that's a reality. > > > > Thx, > > David C. > > > > > On Friday, December 12, 2014, David Gobbi wrote: > > Well, vtkImageReslice is probably not the best "speed" example any more, > it has become fat with all the features that I've added to it over the > years :) And in the old days, a big reason for its speed was that it did > some bit-twiddling to work around the disastrously slow floor() operations > on old CPUs. > > > > However, it is certainly true with modern computer architectures, with > their multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a significant > performance hit, because that takes the CPU core out of the "zone" where it > can work at its full potential. > > > > - David > > > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: > > I'd be fine with it if the header is put into a higher level module such > as GUISupport and has some examples demonstrating its purpose and some > documentation providing a guide on how to use it. I would not agree to > putting this at a place where it may encourage folks to use it in > algorithms and other core functionality. As I mentioned previously, I > already have the unpleasant job of ripping out a number of "convenience" > functionality that are going to have significant impact on performance as > we continue to multi-thread more algorithms. All of these features look > harmless when initially added. Then they find their way into core > functionality slowly but surely. When you are considering 200-way > parallelism (which we are, since we are porting to Intel Xeon Phi already), > any little bit makes a difference. Some simple examples: > > > > * Garbage collection > > * vtkDataArrayTemplate::DataChanged() > > * Abundant use of Modified() > > * Progress reporting > > > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > > > I don't agree that misuse of such features would get caught in reviews. > Very few reviewers are conscious of potential performance issues. Because > very few developers are performance conscious at this point (Dave Gobbi > excepted, he writes amazingly fast code, see image reslice). > > > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear guidelines > on what core classes and algorithms can and cannot do. Once the development > community becomes more aware of these issues and our dashboards are able to > catch performance regressions, we can relax some. > > > > Best, > > -berk > > > > > > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. If > it goes in its own header, then the chances of it being confused with > vtkDebugMacro are significantly reduced. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > > I completely agree with David. This is an application support feature. > There are several examples for such features in VTK, including QVTKWidget > or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK > library itself (other than examples and tests) but in VTK-based > applications. They make the life of application developers easier, allow > standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help application > developers. > > > > Andras > > > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com] > *Sent:* Friday, December 12, 2014 09:16 > *To:* vtk-developers at vtk.org > *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro that > doesn't require a debug build. In my own apps, I often write app-specific > classes that are derived from vtkObject and this is a macro that I might > use from time to time. Unlike Berk, I'm not all that worried that it might > be abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within VTK > itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, and > one that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific example > for why this is needed. The examples are all from Slicer - which to me says > that they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use it > is dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it > can lead to significant performance issues, specially in multi-threaded > code. As it is, there are lot of minor issues like this that we will have > to go and clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Dec 13 15:16:32 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 13 Dec 2014 15:16:32 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: But, Slicer uses ITK, so why not use its logger. On Sat, Dec 13, 2014 at 2:54 PM, Andras Lasso wrote: > Thanks for the pointer, Bill. The logger in ITK is quite nice and the info level logging macro is available in ITK: if the output window is set to itkLoggerOutput then > > itkGenericOutputMacro > > calls > > this->m_Logger->Write(LoggerBase::INFO, t) > > I don't think that adding an ITK-like logger to VTK is necessary, just adding the missing vtkInfo (or vtkGenericOutput) macro would be enough. > > Andras > > > -----Original Message----- > From: Bill Lorensen [mailto:bill.lorensen at gmail.com] > Sent: Saturday, December 13, 2014 13:47 > To: Andras Lasso > Cc: David Cole; David Gobbi; vtk-developers at vtk.org; Berk Geveci > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > ITK has a logger, itk::Logger. > > > On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: >> Yes, sure we don?t need VTK to include a complete logging framework >> such as log4cpp. We just need a convenient mechanism to send messages >> to logging frameworks from VTK. >> >> >> >> What do you think about the following? >> >> >> >> * Allow completely disable vtkInfoMacro by an #ifdef (for example, if >> #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we >> can set VTK_INFO_ENABLED to false by default) >> >> >> >> * Put the macro in a separate header in Common/vtkInfo.h to not make >> the macro visible to VTK classes by default. GUISupport directory >> would be too restrictive, as logging is not related to GUI and there >> are other application-only functions in Common already (such as >> vtkOutputWindow::DisplayText), but any other suggestion is welcome. >> >> >> >> Andras >> >> >> >> From: David Cole [mailto:DLRdave at aol.com] >> Sent: Saturday, December 13, 2014 09:28 >> To: David Gobbi >> Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso >> >> >> Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" >> >> >> >> I agree with Berk. VTK should NOT include the kitchen sink... This >> belongs elsewhere -- there are whole separate libraries that are >> actually focused on logging, and doing it in a high performance, high functionality manner. >> log4cpp, g2log, and boost all come to mind. >> >> Great to hear talk of testing performance regressions on the dashboard >> -- looking forward to the day that's a reality. >> >> >> >> Thx, >> >> David C. >> >> >> >> >> On Friday, December 12, 2014, David Gobbi wrote: >> >> Well, vtkImageReslice is probably not the best "speed" example any >> more, it has become fat with all the features that I've added to it >> over the years :) And in the old days, a big reason for its speed was >> that it did some bit-twiddling to work around the disastrously slow >> floor() operations on old CPUs. >> >> >> >> However, it is certainly true with modern computer architectures, with >> their multiple cores and fast caches, doing _any_ application-level or >> system-level operations within the algorithmic code causes a >> significant performance hit, because that takes the CPU core out of >> the "zone" where it can work at its full potential. >> >> >> >> - David >> >> >> >> On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci >> wrote: >> >> I'd be fine with it if the header is put into a higher level module >> such as GUISupport and has some examples demonstrating its purpose and >> some documentation providing a guide on how to use it. I would not >> agree to putting this at a place where it may encourage folks to use >> it in algorithms and other core functionality. As I mentioned >> previously, I already have the unpleasant job of ripping out a number >> of "convenience" functionality that are going to have significant >> impact on performance as we continue to multi-thread more algorithms. >> All of these features look harmless when initially added. Then they >> find their way into core functionality slowly but surely. When you are >> considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. >> Some simple examples: >> >> >> >> * Garbage collection >> >> * vtkDataArrayTemplate::DataChanged() >> >> * Abundant use of Modified() >> >> * Progress reporting >> >> >> >> Very nice and convenient feature. They may lead to a code running more >> slowly as more threads are added rather than scale up. >> >> >> >> I don't agree that misuse of such features would get caught in >> reviews. Very few reviewers are conscious of potential performance >> issues. Because very few developers are performance conscious at this >> point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). >> >> >> >> So this is not the time to pepper core classes with convenience >> functionality. It is time to simplify and come with very clear >> guidelines on what core classes and algorithms can and cannot do. Once >> the development community becomes more aware of these issues and our >> dashboards are able to catch performance regressions, we can relax some. >> >> >> >> Best, >> >> -berk >> >> >> >> >> >> >> >> >> >> On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi wrote: >> >> However, I have reservations about putting this macro in vtkSetGet.h. >> If it goes in its own header, then the chances of it being confused >> with vtkDebugMacro are significantly reduced. >> >> >> >> - David >> >> >> >> >> >> On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: >> >> I completely agree with David. This is an application support feature. >> There are several examples for such features in VTK, including >> QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to >> be used in VTK library itself (other than examples and tests) but in >> VTK-based applications. They make the life of application developers >> easier, allow standardization, reduces code/feature duplication. >> >> >> >> Adding the macro has negligible impact on VTK but would help >> application developers. >> >> >> >> Andras >> >> >> >> >> >> From: David Gobbi [mailto:david.gobbi at gmail.com] >> Sent: Friday, December 12, 2014 09:16 >> To: vtk-developers at vtk.org >> Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso >> Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" >> >> >> >> On the one hand, I can see that it is useful to have a message macro >> that doesn't require a debug build. In my own apps, I often write >> app-specific classes that are derived from vtkObject and this is a >> macro that I might use from time to time. Unlike Berk, I'm not all >> that worried that it might be abused. For VTK, we have code review. >> >> >> >> On the other hand, I don't think we have a use case for this within >> VTK itself, it would be there purely to serve external VTK classes and apps. >> And people who need this feature could simply put this macro (or a >> similar >> one) in their own header files. >> >> >> >> Summary: this is a convenience feature, IMHO a mostly harmless one, >> and one that I might use. >> >> >> >> - David >> >> >> >> >> >> On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci >> wrote: >> >> I disagree with this change. There is no compelling VTK specific >> example for why this is needed. The examples are all from Slicer - >> which to me says that they can be implemented in Slicer. >> >> >> >> Adding a logging functionality without clear guidelines on how to use >> it is dangerous. It can lead to folks using it for debugging in >> performance critical sections and since it is not compiled out in >> Release builds, it can lead to significant performance issues, >> specially in multi-threaded code. As it is, there are lot of minor >> issues like this that we will have to go and clean up (progress being one of them). >> >> >> >> The main use case seems to be tracking interaction/workflow changes. >> My suggestion is to employ a method appropriate to that. For example, >> events and listeners. >> >> >> >> Best, >> >> -berk >> >> >> >> >> >> On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin >> wrote: >> >> Hi Folks, >> >> While developing 3D Slicer, we created a macro named >> >> vtkInfoMacro >> >> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >> >> We would like to contribute it back to VTK core. >> >> >> >> The associated topic is: >> >> http://review.source.kitware.com/#/c/18385/ >> >> It would be great to get feedback before moving forward. >> >> Thanks >> >> Jc >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From lasso at queensu.ca Sat Dec 13 15:42:45 2014 From: lasso at queensu.ca (Andras Lasso) Date: Sat, 13 Dec 2014 20:42:45 +0000 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: You are right, it?s not necessary to make this additional logging macro available for core VTK library modules. It can be anywhere in VTK where VTK tests, examples, and VTK-based applications can access it. Do you have any suggestion for a good place? Having the macro in VTK allows a standardization on the macro name, parameters, and behavior among all VTK-based applications. The macro would be used in application classes derived from vtkObject. Andras From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: Saturday, December 13, 2014 15:16 To: Andras Lasso Cc: David Cole; David Gobbi; Jean-Christophe Fillion-Robin (JChris.FillionR at kitware.com); vtk-developers at vtk.org Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" Sorry but I remain unconvinced. I haven't heard a compelling reason why this functionality should be available to core VTK modules and why the maintainers of those modules need to worry about it. So far, the only example is for a class in Slicer. Whether this is in a separate header or not, putting it in Common/Core will make it possible for all modules in VTK to use this functionality without any compile errors. As I mentioned, I'd like to see functionality migrate out of Common/Core to outer modules not vice versa. "There are other application-only functions in Common already" is not a good reason why we should cram more in there. Also, vtkOutputWindow is used for VTK-level functionality such as debugging and error reporting. Similar to vtkDebugLeaks. I wouldn't call that application specific. Best, -berk On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso > wrote: Yes, sure we don?t need VTK to include a complete logging framework such as log4cpp. We just need a convenient mechanism to send messages to logging frameworks from VTK. What do you think about the following? * Allow completely disable vtkInfoMacro by an #ifdef (for example, if #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can set VTK_INFO_ENABLED to false by default) * Put the macro in a separate header in Common/vtkInfo.h to not make the macro visible to VTK classes by default. GUISupport directory would be too restrictive, as logging is not related to GUI and there are other application-only functions in Common already (such as vtkOutputWindow::DisplayText), but any other suggestion is welcome. Andras From: David Cole [mailto:DLRdave at aol.com] Sent: Saturday, December 13, 2014 09:28 To: David Gobbi Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" I agree with Berk. VTK should NOT include the kitchen sink... This belongs elsewhere -- there are whole separate libraries that are actually focused on logging, and doing it in a high performance, high functionality manner. log4cpp, g2log, and boost all come to mind. Great to hear talk of testing performance regressions on the dashboard -- looking forward to the day that's a reality. Thx, David C. On Friday, December 12, 2014, David Gobbi > wrote: Well, vtkImageReslice is probably not the best "speed" example any more, it has become fat with all the features that I've added to it over the years :) And in the old days, a big reason for its speed was that it did some bit-twiddling to work around the disastrously slow floor() operations on old CPUs. However, it is certainly true with modern computer architectures, with their multiple cores and fast caches, doing _any_ application-level or system-level operations within the algorithmic code causes a significant performance hit, because that takes the CPU core out of the "zone" where it can work at its full potential. - David On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: I'd be fine with it if the header is put into a higher level module such as GUISupport and has some examples demonstrating its purpose and some documentation providing a guide on how to use it. I would not agree to putting this at a place where it may encourage folks to use it in algorithms and other core functionality. As I mentioned previously, I already have the unpleasant job of ripping out a number of "convenience" functionality that are going to have significant impact on performance as we continue to multi-thread more algorithms. All of these features look harmless when initially added. Then they find their way into core functionality slowly but surely. When you are considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. Some simple examples: * Garbage collection * vtkDataArrayTemplate::DataChanged() * Abundant use of Modified() * Progress reporting Very nice and convenient feature. They may lead to a code running more slowly as more threads are added rather than scale up. I don't agree that misuse of such features would get caught in reviews. Very few reviewers are conscious of potential performance issues. Because very few developers are performance conscious at this point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). So this is not the time to pepper core classes with convenience functionality. It is time to simplify and come with very clear guidelines on what core classes and algorithms can and cannot do. Once the development community becomes more aware of these issues and our dashboards are able to catch performance regressions, we can relax some. Best, -berk On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: However, I have reservations about putting this macro in vtkSetGet.h. If it goes in its own header, then the chances of it being confused with vtkDebugMacro are significantly reduced. - David On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso > wrote: I completely agree with David. This is an application support feature. There are several examples for such features in VTK, including QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK library itself (other than examples and tests) but in VTK-based applications. They make the life of application developers easier, allow standardization, reduces code/feature duplication. Adding the macro has negligible impact on VTK but would help application developers. Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, December 12, 2014 09:16 To: vtk-developers at vtk.org Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" On the one hand, I can see that it is useful to have a message macro that doesn't require a debug build. In my own apps, I often write app-specific classes that are derived from vtkObject and this is a macro that I might use from time to time. Unlike Berk, I'm not all that worried that it might be abused. For VTK, we have code review. On the other hand, I don't think we have a use case for this within VTK itself, it would be there purely to serve external VTK classes and apps. And people who need this feature could simply put this macro (or a similar one) in their own header files. Summary: this is a convenience feature, IMHO a mostly harmless one, and one that I might use. - David On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: I disagree with this change. There is no compelling VTK specific example for why this is needed. The examples are all from Slicer - which to me says that they can be implemented in Slicer. Adding a logging functionality without clear guidelines on how to use it is dangerous. It can lead to folks using it for debugging in performance critical sections and since it is not compiled out in Release builds, it can lead to significant performance issues, specially in multi-threaded code. As it is, there are lot of minor issues like this that we will have to go and clean up (progress being one of them). The main use case seems to be tracking interaction/workflow changes. My suggestion is to employ a method appropriate to that. For example, events and listeners. Best, -berk On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin > wrote: Hi Folks, While developing 3D Slicer, we created a macro named vtkInfoMacro similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". We would like to contribute it back to VTK core. The associated topic is: http://review.source.kitware.com/#/c/18385/ It would be great to get feedback before moving forward. Thanks Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Sat Dec 13 15:53:29 2014 From: lasso at queensu.ca (Andras Lasso) Date: Sat, 13 Dec 2014 20:53:29 +0000 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Slicer uses the CTK logger, which collects log messages from VTK, ITK, Qt, etc. What we miss is a level below, a standard generic (non-error) VTK macro that collects the message, line number, file name, etc. and sends it to the logger. Andras -----Original Message----- From: Bill Lorensen [mailto:bill.lorensen at gmail.com] Sent: Saturday, December 13, 2014 15:17 To: Andras Lasso Cc: David Cole; David Gobbi; vtk-developers at vtk.org; Berk Geveci Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" But, Slicer uses ITK, so why not use its logger. On Sat, Dec 13, 2014 at 2:54 PM, Andras Lasso wrote: > Thanks for the pointer, Bill. The logger in ITK is quite nice and the > info level logging macro is available in ITK: if the output window is > set to itkLoggerOutput then > > itkGenericOutputMacro > > calls > > this->m_Logger->Write(LoggerBase::INFO, t) > > I don't think that adding an ITK-like logger to VTK is necessary, just adding the missing vtkInfo (or vtkGenericOutput) macro would be enough. > > Andras > > > -----Original Message----- > From: Bill Lorensen [mailto:bill.lorensen at gmail.com] > Sent: Saturday, December 13, 2014 13:47 > To: Andras Lasso > Cc: David Cole; David Gobbi; vtk-developers at vtk.org; Berk Geveci > Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > ITK has a logger, itk::Logger. > > > On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: >> Yes, sure we don?t need VTK to include a complete logging framework >> such as log4cpp. We just need a convenient mechanism to send messages >> to logging frameworks from VTK. >> >> >> >> What do you think about the following? >> >> >> >> * Allow completely disable vtkInfoMacro by an #ifdef (for example, if >> #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we >> can set VTK_INFO_ENABLED to false by default) >> >> >> >> * Put the macro in a separate header in Common/vtkInfo.h to not make >> the macro visible to VTK classes by default. GUISupport directory >> would be too restrictive, as logging is not related to GUI and there >> are other application-only functions in Common already (such as >> vtkOutputWindow::DisplayText), but any other suggestion is welcome. >> >> >> >> Andras >> >> >> >> From: David Cole [mailto:DLRdave at aol.com] >> Sent: Saturday, December 13, 2014 09:28 >> To: David Gobbi >> Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso >> >> >> Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" >> >> >> >> I agree with Berk. VTK should NOT include the kitchen sink... This >> belongs elsewhere -- there are whole separate libraries that are >> actually focused on logging, and doing it in a high performance, high functionality manner. >> log4cpp, g2log, and boost all come to mind. >> >> Great to hear talk of testing performance regressions on the >> dashboard >> -- looking forward to the day that's a reality. >> >> >> >> Thx, >> >> David C. >> >> >> >> >> On Friday, December 12, 2014, David Gobbi wrote: >> >> Well, vtkImageReslice is probably not the best "speed" example any >> more, it has become fat with all the features that I've added to it >> over the years :) And in the old days, a big reason for its speed was >> that it did some bit-twiddling to work around the disastrously slow >> floor() operations on old CPUs. >> >> >> >> However, it is certainly true with modern computer architectures, >> with their multiple cores and fast caches, doing _any_ >> application-level or system-level operations within the algorithmic >> code causes a significant performance hit, because that takes the CPU >> core out of the "zone" where it can work at its full potential. >> >> >> >> - David >> >> >> >> On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci >> >> wrote: >> >> I'd be fine with it if the header is put into a higher level module >> such as GUISupport and has some examples demonstrating its purpose >> and some documentation providing a guide on how to use it. I would >> not agree to putting this at a place where it may encourage folks to >> use it in algorithms and other core functionality. As I mentioned >> previously, I already have the unpleasant job of ripping out a number >> of "convenience" functionality that are going to have significant >> impact on performance as we continue to multi-thread more algorithms. >> All of these features look harmless when initially added. Then they >> find their way into core functionality slowly but surely. When you >> are considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. >> Some simple examples: >> >> >> >> * Garbage collection >> >> * vtkDataArrayTemplate::DataChanged() >> >> * Abundant use of Modified() >> >> * Progress reporting >> >> >> >> Very nice and convenient feature. They may lead to a code running >> more slowly as more threads are added rather than scale up. >> >> >> >> I don't agree that misuse of such features would get caught in >> reviews. Very few reviewers are conscious of potential performance >> issues. Because very few developers are performance conscious at this >> point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). >> >> >> >> So this is not the time to pepper core classes with convenience >> functionality. It is time to simplify and come with very clear >> guidelines on what core classes and algorithms can and cannot do. >> Once the development community becomes more aware of these issues and >> our dashboards are able to catch performance regressions, we can relax some. >> >> >> >> Best, >> >> -berk >> >> >> >> >> >> >> >> >> >> On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi wrote: >> >> However, I have reservations about putting this macro in vtkSetGet.h. >> If it goes in its own header, then the chances of it being confused >> with vtkDebugMacro are significantly reduced. >> >> >> >> - David >> >> >> >> >> >> On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: >> >> I completely agree with David. This is an application support feature. >> There are several examples for such features in VTK, including >> QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to >> be used in VTK library itself (other than examples and tests) but in >> VTK-based applications. They make the life of application developers >> easier, allow standardization, reduces code/feature duplication. >> >> >> >> Adding the macro has negligible impact on VTK but would help >> application developers. >> >> >> >> Andras >> >> >> >> >> >> From: David Gobbi [mailto:david.gobbi at gmail.com] >> Sent: Friday, December 12, 2014 09:16 >> To: vtk-developers at vtk.org >> Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso >> Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" >> >> >> >> On the one hand, I can see that it is useful to have a message macro >> that doesn't require a debug build. In my own apps, I often write >> app-specific classes that are derived from vtkObject and this is a >> macro that I might use from time to time. Unlike Berk, I'm not all >> that worried that it might be abused. For VTK, we have code review. >> >> >> >> On the other hand, I don't think we have a use case for this within >> VTK itself, it would be there purely to serve external VTK classes and apps. >> And people who need this feature could simply put this macro (or a >> similar >> one) in their own header files. >> >> >> >> Summary: this is a convenience feature, IMHO a mostly harmless one, >> and one that I might use. >> >> >> >> - David >> >> >> >> >> >> On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci >> >> wrote: >> >> I disagree with this change. There is no compelling VTK specific >> example for why this is needed. The examples are all from Slicer - >> which to me says that they can be implemented in Slicer. >> >> >> >> Adding a logging functionality without clear guidelines on how to use >> it is dangerous. It can lead to folks using it for debugging in >> performance critical sections and since it is not compiled out in >> Release builds, it can lead to significant performance issues, >> specially in multi-threaded code. As it is, there are lot of minor >> issues like this that we will have to go and clean up (progress being one of them). >> >> >> >> The main use case seems to be tracking interaction/workflow changes. >> My suggestion is to employ a method appropriate to that. For example, >> events and listeners. >> >> >> >> Best, >> >> -berk >> >> >> >> >> >> On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin >> wrote: >> >> Hi Folks, >> >> While developing 3D Slicer, we created a macro named >> >> vtkInfoMacro >> >> similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". >> >> We would like to contribute it back to VTK core. >> >> >> >> The associated topic is: >> >> http://review.source.kitware.com/#/c/18385/ >> >> It would be great to get feedback before moving forward. >> >> Thanks >> >> Jc >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From dmsurti at gmail.com Sun Dec 14 07:44:47 2014 From: dmsurti at gmail.com (Deepak Surti) Date: Sun, 14 Dec 2014 18:14:47 +0530 Subject: [vtk-developers] Building VTK with Python Wrapping on Cent OS 5.11 64 bit fails Message-ID: Hi, I am trying to get a VTK build working with Python Wrapping on Cent OS 5.11 64 bit. I have not been able to build any of VTK 5.10, VTK 6.1 or VTK from master/nightly branch. The build fails in a different target, for each version. Say if I turn off BUILD_SHARED_STATIC_LIBS == OFF, then VTK master build fails in target vtkproj4. I also realized that Mesa OpenGL version = 1.2, so OpenLG2 rendering support will not likely work for this build. My specific questions are: 1. Is Cent OS 5.11 platform supported for VTK? If yes, upto which version? 2. Will OpenGL2 rendering be possible on Cent OS 5.11? I also checked VTK CDash dashboard ( https://open.cdash.org/index.php?project=VTK), but do not see Cent OS 5.11 as a tested platform. Any info/suggestions/questions welcome and helpful. Thanks, Deepak ============================ *My Env Setup To build VTK* - VMWare Fusion 6.0.5 - Mac OS X 10.9 (VMWare Host) - Cent OS 6.6 64 bit (Running as Guest in VMWare), with Mesa 3d OpenGL drivers as here: http://mesa3d.org/vmware-guest.html -- http://deepaksurti.com To see a miracle, be the miracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Sun Dec 14 09:20:38 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sun, 14 Dec 2014 07:20:38 -0700 Subject: [vtk-developers] Building VTK with Python Wrapping on Cent OS 5.11 64 bit fails In-Reply-To: References: Message-ID: Hi Deepak, Even though CentOS 5.11 isn't on the dashboard, it should definitely work. You might be missing one or more .rpm package that is necessary for VTK. Python wrapping requires BUILD_SHARED_LIBS=ON. Please copy the error to your email, because that will give us some clues as to why the build fails. - David On Sun, Dec 14, 2014 at 5:44 AM, Deepak Surti wrote: > > Hi, > > I am trying to get a VTK build working with Python Wrapping on Cent OS > 5.11 64 bit. > > I have not been able to build any of VTK 5.10, VTK 6.1 or VTK from > master/nightly branch. The build fails in a different target, for each > version. Say if I turn off BUILD_SHARED_STATIC_LIBS == OFF, then VTK master > build fails in target vtkproj4. I also realized that Mesa OpenGL version = > 1.2, so OpenLG2 rendering support will not likely work for this build. > > My specific questions are: > > 1. Is Cent OS 5.11 platform supported for VTK? If yes, upto which version? > 2. Will OpenGL2 rendering be possible on Cent OS 5.11? > > I also checked VTK CDash dashboard ( > https://open.cdash.org/index.php?project=VTK), but do not see Cent OS > 5.11 as a tested platform. > > Any info/suggestions/questions welcome and helpful. > > Thanks, > Deepak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Sun Dec 14 10:05:21 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sun, 14 Dec 2014 08:05:21 -0700 Subject: [vtk-developers] Building VTK with Python Wrapping on Cent OS 5.11 64 bit fails In-Reply-To: References: Message-ID: Hi Deepak, In your cache, these two variable appear to be filled with garbage for some reason, when they should be empty: CMAKE_EXE_LINKER_FLAGS:STRING=' ' CMAKE_MODULE_LINKER_FLAGS:STRING=' ' For the error log, it's best not to send the whole file, because it contains the output from a bunch of cmake try-compiles that aren't relevant to the main build itself. Just run "make" and copy any console output that contains error reports into your next email. - David On Sun, Dec 14, 2014 at 7:54 AM, Deepak Surti wrote: > > Hi David, > > I have attached the CMakeCache.txt and CMakeError.log files. This is while > trying to build VTK 6.1 on Cent OS 5.11 64 bit under VMWare. > > Also, as Mesa 3D OpenGL version is 1.2, will OpenGL2 support be even > possible for VTK on Cent OS 5.11 ? > > Thanks, > Deepak > > On Sun, Dec 14, 2014 at 7:50 PM, David Gobbi > wrote: >> >> Hi Deepak, >> >> Even though CentOS 5.11 isn't on the dashboard, it should definitely work. >> You might be missing one or more .rpm package that is necessary for VTK. >> Python wrapping requires BUILD_SHARED_LIBS=ON. >> >> Please copy the error to your email, because that will give us some clues >> as to why the build fails. >> >> - David >> >> >> On Sun, Dec 14, 2014 at 5:44 AM, Deepak Surti wrote: >>> >>> Hi, >>> >>> I am trying to get a VTK build working with Python Wrapping on Cent OS >>> 5.11 64 bit. >>> >>> I have not been able to build any of VTK 5.10, VTK 6.1 or VTK from >>> master/nightly branch. The build fails in a different target, for each >>> version. Say if I turn off BUILD_SHARED_STATIC_LIBS == OFF, then VTK master >>> build fails in target vtkproj4. I also realized that Mesa OpenGL version = >>> 1.2, so OpenLG2 rendering support will not likely work for this build. >>> >>> My specific questions are: >>> >>> 1. Is Cent OS 5.11 platform supported for VTK? If yes, upto which >>> version? >>> 2. Will OpenGL2 rendering be possible on Cent OS 5.11? >>> >>> I also checked VTK CDash dashboard ( >>> https://open.cdash.org/index.php?project=VTK), but do not see Cent OS >>> 5.11 as a tested platform. >>> >>> Any info/suggestions/questions welcome and helpful. >>> >>> Thanks, >>> Deepak >>> >> > > -- > http://deepaksurti.com > To see a miracle, be the miracle. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Dec 16 17:45:58 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 16 Dec 2014 17:45:58 -0500 Subject: [vtk-developers] kamino.kitware dashboard poorly named submission... In-Reply-To: <20141209230546.1570153853@mail.rogue-research.com> References: <20141209230546.1570153853@mail.rogue-research.com> Message-ID: 1) yeah. I'll make it use gcc until demote it off of nightly expected until it proves itself worthy. 2) neither. It is ctest's fault. See http://www.cmake.org/Bug/view.php?id=7867 David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Dec 9, 2014 at 6:05 PM, Sean McBride wrote: > > Hi all, > > See: > > > The page has 3 confusing lines, pasted here: > > Build Name: Mac10.7.5-gcc-release-x86_64-nightly_master (view notes) > Compiler Version: unknown > -- The CXX compiler identification is Clang 3.1.0 > > So two issues: > 1) if this machine is really using clang, I dare say "gcc" should not be > in its submission name :) > 2) why does it say "Compiler Version: unknown". Is that cdash or cmake's > fault? > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Dec 18 06:33:25 2014 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Dec 2014 06:33:25 -0500 Subject: [vtk-developers] File removed? Message-ID: The VTK wiki examples dashboard now produces a build error (as of all the attempted builds since Dec. 6th): vtkwikiexamples\Cxx\Visualization\Shadows.cxx(37) : fatal error C1083: Cannot open include file: 'vtkShadowMapBakerPass.h': No such file or directory Was the file intentionally removed? (This is on a machine running VS 2013, Ninja generator, OpenGL2 backend.) Thanks, David C. From bill.lorensen at gmail.com Thu Dec 18 08:30:45 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 18 Dec 2014 08:30:45 -0500 Subject: [vtk-developers] File removed? In-Reply-To: References: Message-ID: Dave, That file is in the OpenGL backend, but I don't see it in the OpenGL2 backend. Bill On Thu, Dec 18, 2014 at 6:33 AM, David Cole via vtk-developers wrote: > The VTK wiki examples dashboard now produces a build error (as of all > the attempted builds since Dec. 6th): > > vtkwikiexamples\Cxx\Visualization\Shadows.cxx(37) : fatal error C1083: > Cannot open include file: 'vtkShadowMapBakerPass.h': No such file or > directory > > Was the file intentionally removed? > > (This is on a machine running VS 2013, Ninja generator, OpenGL2 backend.) > > > Thanks, > David C. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Thu Dec 18 09:03:23 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 18 Dec 2014 07:03:23 -0700 Subject: [vtk-developers] Valgrind Dashboard Message-ID: The valgrind tests are almost green, but there are still a few leaks in vtkGDALRasterReader: https://open.cdash.org/viewDynamicAnalysisFile.php?id=3338863 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Dec 18 09:25:38 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 18 Dec 2014 09:25:38 -0500 Subject: [vtk-developers] Valgrind Dashboard In-Reply-To: References: Message-ID: Thanks Dave, I pinged Aashish a couple of days ago. He's at a conference right now, but will fix it when he gets back to the office. Unless one of us beats him to it of course. :) David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 18, 2014 at 9:03 AM, David Gobbi wrote: > > The valgrind tests are almost green, but there are still a few leaks > in vtkGDALRasterReader: > > https://open.cdash.org/viewDynamicAnalysisFile.php?id=3338863 > > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Dec 18 09:28:39 2014 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 18 Dec 2014 09:28:39 -0500 Subject: [vtk-developers] File removed? In-Reply-To: References: Message-ID: <09a1367b6e59c3f6808a064f0fcbb306@mail.gmail.com> Yes, shadow passes are not in the OpenGL2 backend yet. I would like to convert them over but it is not done yet. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen Sent: Thursday, December 18, 2014 8:31 AM To: David Cole Cc: vtkdev Subject: Re: [vtk-developers] File removed? Dave, That file is in the OpenGL backend, but I don't see it in the OpenGL2 backend. Bill On Thu, Dec 18, 2014 at 6:33 AM, David Cole via vtk-developers wrote: > The VTK wiki examples dashboard now produces a build error (as of all > the attempted builds since Dec. 6th): > > vtkwikiexamples\Cxx\Visualization\Shadows.cxx(37) : fatal error C1083: > Cannot open include file: 'vtkShadowMapBakerPass.h': No such file or > directory > > Was the file intentionally removed? > > (This is on a machine running VS 2013, Ninja generator, OpenGL2 > backend.) > > > Thanks, > David C. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From dave.demarle at kitware.com Thu Dec 18 09:37:32 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 18 Dec 2014 09:37:32 -0500 Subject: [vtk-developers] vtk dashboard Message-ID: On a related note here are the tests that need attention on the nightly expected section: 17 FAILURES vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 , ['Mac10.5-gcc-dbg-ppc-shared'] vtkFiltersSources-TestPrintSelf , 1 , ['Win64-VS10'] vtkFiltersAMRPython-TestAMRResampleFilter , 1 , ['Mac10.5-gcc-dbg-ppc-shared'] vtkIOEnSightTcl-EnSightBlow1Bin , 1 , ['Arch-GCC-4.9-x86_64-release'] vtkChartsCorePython-TestBarGraph , 1 , ['Linux-gcc'] vtkIOADIOSCxx-MPI-TestADIOSSphereWR , 1 , ['CentOS-6.5_GCC-4.4.7'] vtkIOEnSightTcl-EnSightBlow2ASCII , 1 , ['Arch-GCC-4.9-x86_64-release'] vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 , ['Win32-vs71-static'] vtkRenderingCoreCxx-TestPointSelection , 1 , ['Ubuntu-master'] vtkFiltersCorePython-multipleComponentContour , 1 , ['Arch-GCC-4.9-x86_64-debug'] JavaRendering , 2 , ['Mac10.6-gcc-dbg-i386', 'Mac10.7.5-clang-release-x86_64-nightly_master'] vtkFiltersModelingPython-contour3DAll , 2 , ['Arch-Clang-3.3-x86_64-debug', 'Arch-GCC-4.9-x86_64-debug'] vtkChartsCoreCxx-TestChartXYZ , 2 , ['Mac10.10-clang-dbg-x86_64', 'Mac10.10-clang-rel-x86_64'] vtkRenderingCoreCxx-TestCompositePolyDataMapper2 , 3 , ['Win32-vs9-Shared', 'Win32-vs9-Static', 'Win32-vs71-static'] vtkChartsCoreCxx-TestLinePlotAxisFonts , 3 , ['Win64-VS10', 'Win32-vs11-Static', 'Win32-vs11-Shared'] vtkParallelMPI4PyPython-TestParallelNumpy , 3 , ['Arch-Clang-3.3-x86_64-debug', 'Arch-GCC-4.9-x86_64-debug', 'Arch-GCC-4.9-x86_64-release'] vtkRenderingCoreCxx-TestActor2D , 5 , ['Win32-ninja-Debug', 'Win32-vs9-Shared', 'Win32-ninja-Release', 'Win32-vs9-Static', 'Win32-vs71-static'] David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Dec 18 09:50:08 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 18 Dec 2014 07:50:08 -0700 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: Message-ID: On Thu, Dec 18, 2014 at 7:37 AM, David E DeMarle wrote: > > On a related note here are the tests that need attention on the nightly > expected section: > Thanks for the summary! - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Dec 18 09:47:57 2014 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Dec 2014 09:47:57 -0500 Subject: [vtk-developers] File removed? In-Reply-To: References: Message-ID: So that's a problem, right? Header files should exist in *neither* backend or in *both* backends, shouldn't they? I don't want to have to write conditional #include based on a backend setting..... do you? Is it a backend or is it a public API? (Rhetorical, no need for flames, :-) On Thu, Dec 18, 2014 at 8:30 AM, Bill Lorensen wrote: > Dave, > > That file is in the OpenGL backend, but I don't see it in the OpenGL2 backend. > > Bill > > > On Thu, Dec 18, 2014 at 6:33 AM, David Cole via vtk-developers > wrote: >> The VTK wiki examples dashboard now produces a build error (as of all >> the attempted builds since Dec. 6th): >> >> vtkwikiexamples\Cxx\Visualization\Shadows.cxx(37) : fatal error C1083: >> Cannot open include file: 'vtkShadowMapBakerPass.h': No such file or >> directory >> >> Was the file intentionally removed? >> >> (This is on a machine running VS 2013, Ninja generator, OpenGL2 backend.) >> >> >> Thanks, >> David C. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Thu Dec 18 09:55:17 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 18 Dec 2014 09:55:17 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: Message-ID: But wait there's more: The continuous section's problems are: * x TestLinePloxAxisFonts * x TestActor2D * x TestCompositePolyDataMapper2 * JavaRendering * kargad's somewhat recent flakiness. I've already reprimanded the responsible parties for x's, they are looking into it. Sebastien do you have some time to look at the JavaRendering test? I'll look and see if I can resolve Kargad's general flakiness. The gerrit section's current problems are: * TestPointSelection (started on https://open.cdash.org/index.php?project=VTK&date=2014-12-15) for no good reason that I've determined yet. * TestEdgeFlags (on tarvalon) has been broken since it was first committed. Joachim please look at this ASAP. * tarvalon hasn't been submitting recently Robert can you kick Tarvalon again? David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 18, 2014 at 9:50 AM, David Gobbi wrote: > > On Thu, Dec 18, 2014 at 7:37 AM, David E DeMarle > wrote: >> >> On a related note here are the tests that need attention on the nightly >> expected section: >> > > Thanks for the summary! > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Dec 18 12:06:27 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Dec 2014 12:06:27 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: Message-ID: <20141218170627.958519866@mail.rogue-research.com> On Thu, 18 Dec 2014 09:55:17 -0500, David E DeMarle said: >But wait there's more: Note that my 'torture' dashboard may give better diagnostics of any failing test. One new failure today, which I think I've seen intermittently fail on my machine too is: VTK/Web/Core/vtkDataEncoder.cxx:152:25: runtime error: load of value 85, which is not a valid value for type 'bool' Perhaps the 'bool Done' ivar is sometimes uninitialized and gets random values? 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 sebastien.jourdain at kitware.com Thu Dec 18 12:08:16 2014 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 18 Dec 2014 10:08:16 -0700 Subject: [vtk-developers] vtk dashboard In-Reply-To: <20141218170627.958519866@mail.rogue-research.com> References: <20141218170627.958519866@mail.rogue-research.com> Message-ID: Thanks Sean, I'll look into that. Seb On Thu, Dec 18, 2014 at 10:06 AM, Sean McBride wrote: > > On Thu, 18 Dec 2014 09:55:17 -0500, David E DeMarle said: > > >But wait there's more: > > Note that my 'torture' dashboard may give better diagnostics of any > failing test. One new failure today, which I think I've seen > intermittently fail on my machine too is: > > > > VTK/Web/Core/vtkDataEncoder.cxx:152:25: runtime error: load of value 85, > which is not a valid value for type 'bool' > > Perhaps the 'bool Done' ivar is sometimes uninitialized and gets random > values? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Thu Dec 18 12:16:11 2014 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 18 Dec 2014 10:16:11 -0700 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: <20141218170627.958519866@mail.rogue-research.com> Message-ID: This is weird. The Done is properly initialized and get only set to "true" or "false"... vtkSharedData() : Done(false), ActiveThreadCount(0) { } On Thu, Dec 18, 2014 at 10:08 AM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > > Thanks Sean, > > I'll look into that. > > Seb > > On Thu, Dec 18, 2014 at 10:06 AM, Sean McBride > wrote: >> >> On Thu, 18 Dec 2014 09:55:17 -0500, David E DeMarle said: >> >> >But wait there's more: >> >> Note that my 'torture' dashboard may give better diagnostics of any >> failing test. One new failure today, which I think I've seen >> intermittently fail on my machine too is: >> >> >> >> VTK/Web/Core/vtkDataEncoder.cxx:152:25: runtime error: load of value 85, >> which is not a valid value for type 'bool' >> >> Perhaps the 'bool Done' ivar is sometimes uninitialized and gets random >> values? >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Dec 18 13:15:00 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 18 Dec 2014 13:15:00 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: <20141218170627.958519866@mail.rogue-research.com> Message-ID: <20141218181500.GA8961@megas.kitwarein.com> On Thu, Dec 18, 2014 at 10:16:11 -0700, Sebastien Jourdain wrote: > This is weird. The Done is properly initialized and get only set to "true" > or "false"... > > vtkSharedData() : Done(false), ActiveThreadCount(0) > > { > > } Could a buffer overflow be corrupting Done? --Ben From sebastien.jourdain at kitware.com Thu Dec 18 13:16:07 2014 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 18 Dec 2014 11:16:07 -0700 Subject: [vtk-developers] vtk dashboard In-Reply-To: <20141218181500.GA8961@megas.kitwarein.com> References: <20141218170627.958519866@mail.rogue-research.com> <20141218181500.GA8961@megas.kitwarein.com> Message-ID: That's my thought, but will need a deeper investigation. On Thu, Dec 18, 2014 at 11:15 AM, Ben Boeckel wrote: > > On Thu, Dec 18, 2014 at 10:16:11 -0700, Sebastien Jourdain wrote: > > This is weird. The Done is properly initialized and get only set to > "true" > > or "false"... > > > > vtkSharedData() : Done(false), ActiveThreadCount(0) > > > > { > > > > } > > Could a buffer overflow be corrupting Done? > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Dec 18 13:23:37 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 18 Dec 2014 11:23:37 -0700 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: <20141218170627.958519866@mail.rogue-research.com> <20141218181500.GA8961@megas.kitwarein.com> Message-ID: In case you decide to give it a shot, here is a possibility: "Done" is the first member in the class, and the class has no virtual methods, nor does it have any superclass to inherit them from, therefor the class has no vtable. This means that the address of "Done" is identical to the address of the vtkSharedData object itself. Therefore, a bad write through a "vtkSharedData *" will directly write to the "Done" member, even if the write is only a single byte in size. For buffer overruns, a likely culprit is vtkDataEncoder::vtkInternals, which has a vtkSharedData member. The member just before it is a vtkMultiThreader declared with vtkNew. Since when can vtkNew be used to declare member variables? I though that vtkSmartPointer was supposed to be used for that. Well, anyway, I'm kind of trying to make the point that the fact that it "might not be easy" to find the error is pretty obvious... but it's definitely worth at least looking through the code. - David On Thu, Dec 18, 2014 at 11:16 AM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > > That's my thought, but will need a deeper investigation. > > On Thu, Dec 18, 2014 at 11:15 AM, Ben Boeckel > wrote: >> >> On Thu, Dec 18, 2014 at 10:16:11 -0700, Sebastien Jourdain wrote: >> > This is weird. The Done is properly initialized and get only set to >> "true" >> > or "false"... >> > >> > vtkSharedData() : Done(false), ActiveThreadCount(0) >> > >> > { >> > >> > } >> >> Could a buffer overflow be corrupting Done? >> >> --Ben >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Dec 18 13:42:57 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 18 Dec 2014 13:42:57 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: <20141218170627.958519866@mail.rogue-research.com> <20141218181500.GA8961@megas.kitwarein.com> Message-ID: On Thu, Dec 18, 2014 at 1:23 PM, David Gobbi wrote: > Since when can vtkNew be used to declare member variables? > I though that vtkSmartPointer was supposed to be used for that. It was designed to be used in that way, but it is strongly owned, i.e. you cannot override with your own member of the same (or more derived) type. See http://www.kitware.com/source/home/post/7 for a write up that should still be pretty accurate. Marcus From sean at rogue-research.com Thu Dec 18 17:10:42 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Dec 2014 17:10:42 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: References: <20141218170627.958519866@mail.rogue-research.com> <20141218181500.GA8961@megas.kitwarein.com> Message-ID: <20141218221042.39874143@mail.rogue-research.com> On Thu, 18 Dec 2014 11:23:37 -0700, David Gobbi said: >For buffer overruns... Sound like trying valgrind and/or ASan could help. Does the valgrind bot exercise the Web stuff? 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 jchris.fillionr at kitware.com Thu Dec 18 18:19:00 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 18 Dec 2014 18:19:00 -0500 Subject: [vtk-developers] python-vtk6 ubuntu package - Fail to import vtk - issue has been reported on launchpad Message-ID: Hi Folks, FYI - On ubuntu, importing vtk after installing python-vtk6 was failing. The problem has been reported here: https://bugs.launchpad.net/ubuntu/+source/vtk6/+bug/1404045 Hth Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Dec 18 18:59:10 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 18 Dec 2014 18:59:10 -0500 Subject: [vtk-developers] python-vtk6 ubuntu package - Fail to import vtk - issue has been reported on launchpad In-Reply-To: References: Message-ID: <20141218235910.GB10965@bronto-burt.dev.benboeckel.net> [ CC'ing Anton who reported a similar error in ParaView on Debian. ] On Thu, Dec 18, 2014 at 18:19:00 -0500, Jean-Christophe Fillion-Robin wrote: > FYI - On ubuntu, importing vtk after installing python-vtk6 was failing. > The problem has been reported here: > > https://bugs.launchpad.net/ubuntu/+source/vtk6/+bug/1404045 They should probably sync with Debian. VTK5 in Debian shipped with a script which relinked Python stuff all over the place and is no longer necessary in VTK6. The offending file was: http://anonscm.debian.org/gitweb/?p=debian-science/packages/vtk6.git;a=blob;f=debian/python-vtk6.links;h=7b07780ed3d933ab944f5398d6cc1e3daa57d953;hb=HEAD and generate_links.sh. --Ben From ben.boeckel at kitware.com Thu Dec 18 19:02:22 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 18 Dec 2014 19:02:22 -0500 Subject: [vtk-developers] python-vtk6 ubuntu package - Fail to import vtk - issue has been reported on launchpad In-Reply-To: <20141218235910.GB10965@bronto-burt.dev.benboeckel.net> References: <20141218235910.GB10965@bronto-burt.dev.benboeckel.net> Message-ID: <20141219000222.GC10965@bronto-burt.dev.benboeckel.net> On Thu, Dec 18, 2014 at 18:59:10 -0500, Ben Boeckel wrote: > The offending file was: > > http://anonscm.debian.org/gitweb/?p=debian-science/packages/vtk6.git;a=blob;f=debian/python-vtk6.links;h=7b07780ed3d933ab944f5398d6cc1e3daa57d953;hb=HEAD > > and generate_links.sh. And looking at the -debian.tar.xz file, it is indeed doing generate_links.sh. I'll see if I can remember my Launchpad login. --Ben From alex.molinar at primexx.com Fri Dec 19 10:41:12 2014 From: alex.molinar at primexx.com (ahype) Date: Fri, 19 Dec 2014 08:41:12 -0700 (MST) Subject: [vtk-developers] vtkThreshold Message-ID: <1419003672212-5729920.post@n5.nabble.com> Im getting an error when trying to run code that used to work. ERROR: In C:\Dashboards\Releases\rc-2380face\VTK\Graphics\vtkThreshold.cxx, line 122 vtkThreshold (19801760): You have set the attribute mode on vtkThreshold. This method is deprecated, please use SetInputArrayToProcess instead. Here is the original code. vtkPointDataToCellData p2c p2c SetInput [contGeom GetOutput] vtkThreshold thresh thresh SetInput [contGeom GetOutput] thresh SetAttributeModeToUsePointData -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkThreshold-tp5729920.html Sent from the VTK - Dev mailing list archive at Nabble.com. From bill.lorensen at gmail.com Fri Dec 19 11:07:44 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Dec 2014 11:07:44 -0500 Subject: [vtk-developers] vtkThreshold In-Reply-To: <1419003672212-5729920.post@n5.nabble.com> References: <1419003672212-5729920.post@n5.nabble.com> Message-ID: These two examples may be useful: http://vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ThresholdCells http://vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ThresholdPoints On Fri, Dec 19, 2014 at 10:41 AM, ahype wrote: > Im getting an error when trying to run code that used to work. > > ERROR: In C:\Dashboards\Releases\rc-2380face\VTK\Graphics\vtkThreshold.cxx, > line 122 > vtkThreshold (19801760): You have set the attribute mode on vtkThreshold. > This method is deprecated, please use SetInputArrayToProcess instead. > > Here is the original code. > > vtkPointDataToCellData p2c > p2c SetInput [contGeom GetOutput] > vtkThreshold thresh > thresh SetInput [contGeom GetOutput] > thresh SetAttributeModeToUsePointData > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/vtkThreshold-tp5729920.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From alex.molinar at primexx.com Fri Dec 19 11:39:28 2014 From: alex.molinar at primexx.com (ahype) Date: Fri, 19 Dec 2014 09:39:28 -0700 (MST) Subject: [vtk-developers] vtkThreshold In-Reply-To: References: <1419003672212-5729920.post@n5.nabble.com> Message-ID: <000401d01baa$509e0d30$f1da2790$@primexx.com> Unfortunately I have no experience in c++. I exclusively use TCL. No example of tcl code is available for SetInputArrayToProcess. From: Bill Lorensen [via VTK] [mailto:ml-node+s1045678n5729922h51 at n5.nabble.com] Sent: Friday, December 19, 2014 10:08 AM To: ahype Subject: Re: vtkThreshold These two examples may be useful: http://vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ThresholdCells http://vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ThresholdPoints On Fri, Dec 19, 2014 at 10:41 AM, ahype <[hidden email]> wrote: > Im getting an error when trying to run code that used to work. > > ERROR: In C:\Dashboards\Releases\rc-2380face\VTK\Graphics\vtkThreshold.cxx, > line 122 > vtkThreshold (19801760): You have set the attribute mode on vtkThreshold. > This method is deprecated, please use SetInputArrayToProcess instead. > > Here is the original code. > > vtkPointDataToCellData p2c > p2c SetInput [contGeom GetOutput] > vtkThreshold thresh > thresh SetInput [contGeom GetOutput] > thresh SetAttributeModeToUsePointData > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/vtkThreshold-tp5729920.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers _____ If you reply to this email, your message will be added to the discussion below: http://vtk.1045678.n5.nabble.com/vtkThreshold-tp5729920p5729922.html To unsubscribe from vtkThreshold, click here . NAML -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkThreshold-tp5729920p5729924.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Dec 19 13:07:19 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 19 Dec 2014 13:07:19 -0500 Subject: [vtk-developers] vtk dashboard In-Reply-To: <20141218221042.39874143@mail.rogue-research.com> References: <20141218170627.958519866@mail.rogue-research.com> <20141218181500.GA8961@megas.kitwarein.com> <20141218221042.39874143@mail.rogue-research.com> Message-ID: Nope. karego-at doesn't do any of the wrapping dependent tests. It is an old mac mini and the 916 tests it does now take it 7 hours to do under valgrind. Eventually I'll get my greedy paws on some newer hardware along with the time to set it up. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 18, 2014 at 5:10 PM, Sean McBride wrote: > > On Thu, 18 Dec 2014 11:23:37 -0700, David Gobbi said: > > >For buffer overruns... > > Sound like trying valgrind and/or ASan could help. > > Does the valgrind bot exercise the Web stuff? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Fri Dec 19 14:30:06 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 19 Dec 2014 14:30:06 -0500 Subject: [vtk-developers] File removed? In-Reply-To: References: Message-ID: On Thu, Dec 18, 2014 at 9:47 AM, David Cole via vtk-developers wrote: > So that's a problem, right? > > Header files should exist in *neither* backend or in *both* backends, > shouldn't they? I don't want to have to write conditional #include > based on a backend setting..... do you? Is it a backend or is it a > public API? (Rhetorical, no need for flames, :-) > I think it is a backend, with implementation files. If you are including files from either one then I am afraid you may have to write conditional code depending on the backend you are using. We are not guaranteeing all files in OpenGL are in OpenGL2, and the painter headers were moved into OpenGL and will likely never see counterparts in the OpenGL2 backend. We should codify some of this in our documentation to make it clear. Marcus From bill.lorensen at gmail.com Fri Dec 19 15:32:56 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Dec 2014 15:32:56 -0500 Subject: [vtk-developers] File removed? In-Reply-To: References: Message-ID: I will fix the example to make sure it will only build if the opengl backend is used. On Fri, Dec 19, 2014 at 2:30 PM, Marcus D. Hanwell wrote: > On Thu, Dec 18, 2014 at 9:47 AM, David Cole via vtk-developers > wrote: >> So that's a problem, right? >> >> Header files should exist in *neither* backend or in *both* backends, >> shouldn't they? I don't want to have to write conditional #include >> based on a backend setting..... do you? Is it a backend or is it a >> public API? (Rhetorical, no need for flames, :-) >> > I think it is a backend, with implementation files. If you are > including files from either one then I am afraid you may have to write > conditional code depending on the backend you are using. We are not > guaranteeing all files in OpenGL are in OpenGL2, and the painter > headers were moved into OpenGL and will likely never see counterparts > in the OpenGL2 backend. We should codify some of this in our > documentation to make it clear. > > Marcus -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Sat Dec 20 10:49:14 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 20 Dec 2014 10:49:14 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: I looked at our current structure and could not find a suitable place that would allow for non-GUI classes to have access to this but not the core classes. It is probably not worth creating a module to just add this header so I recommend keeping it in Slicer for now. Best, -berk On Sat, Dec 13, 2014 at 3:42 PM, Andras Lasso wrote: > > You are right, it?s not necessary to make this additional logging macro > available for core VTK library modules. It can be anywhere in VTK where VTK > tests, examples, and VTK-based applications can access it. Do you have any > suggestion for a good place? > > > > Having the macro in VTK allows a standardization on the macro name, > parameters, and behavior among all VTK-based applications. The macro would > be used in application classes derived from vtkObject. > > > > Andras > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* Saturday, December 13, 2014 15:16 > *To:* Andras Lasso > *Cc:* David Cole; David Gobbi; Jean-Christophe Fillion-Robin ( > JChris.FillionR at kitware.com); vtk-developers at vtk.org > > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > Sorry but I remain unconvinced. I haven't heard a compelling reason why > this functionality should be available to core VTK modules and why the > maintainers of those modules need to worry about it. So far, the only > example is for a class in Slicer. > > > > Whether this is in a separate header or not, putting it in Common/Core > will make it possible for all modules in VTK to use this functionality > without any compile errors. As I mentioned, I'd like to see functionality > migrate out of Common/Core to outer modules not vice versa. "There are > other application-only functions in Common already" is not a good reason > why we should cram more in there. Also, vtkOutputWindow is used for > VTK-level functionality such as debugging and error reporting. Similar to > vtkDebugLeaks. I wouldn't call that application specific. > > > > Best, > > -berk > > > > On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: > > Yes, sure we don?t need VTK to include a complete logging framework such > as log4cpp. We just need a convenient mechanism to send messages to logging > frameworks from VTK. > > > > What do you think about the following? > > > > * Allow completely disable vtkInfoMacro by an #ifdef (for example, if > #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can > set VTK_INFO_ENABLED to false by default) > > > > * Put the macro in a separate header in Common/vtkInfo.h to not make the > macro visible to VTK classes by default. GUISupport directory would be too > restrictive, as logging is not related to GUI and there are other > application-only functions in Common already (such as > vtkOutputWindow::DisplayText), but any other suggestion is welcome. > > > > Andras > > > > *From:* David Cole [mailto:DLRdave at aol.com] > *Sent:* Saturday, December 13, 2014 09:28 > *To:* David Gobbi > *Cc:* Berk Geveci; vtk-developers at vtk.org; Andras Lasso > > > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I agree with Berk. VTK should NOT include the kitchen sink... This belongs > elsewhere -- there are whole separate libraries that are actually focused > on logging, and doing it in a high performance, high functionality manner. > log4cpp, g2log, and boost all come to mind. > > Great to hear talk of testing performance regressions on the dashboard -- > looking forward to the day that's a reality. > > > > Thx, > > David C. > > > > > On Friday, December 12, 2014, David Gobbi wrote: > > Well, vtkImageReslice is probably not the best "speed" example any more, > it has become fat with all the features that I've added to it over the > years :) And in the old days, a big reason for its speed was that it did > some bit-twiddling to work around the disastrously slow floor() operations > on old CPUs. > > > > However, it is certainly true with modern computer architectures, with > their multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a significant > performance hit, because that takes the CPU core out of the "zone" where it > can work at its full potential. > > > > - David > > > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: > > I'd be fine with it if the header is put into a higher level module such > as GUISupport and has some examples demonstrating its purpose and some > documentation providing a guide on how to use it. I would not agree to > putting this at a place where it may encourage folks to use it in > algorithms and other core functionality. As I mentioned previously, I > already have the unpleasant job of ripping out a number of "convenience" > functionality that are going to have significant impact on performance as > we continue to multi-thread more algorithms. All of these features look > harmless when initially added. Then they find their way into core > functionality slowly but surely. When you are considering 200-way > parallelism (which we are, since we are porting to Intel Xeon Phi already), > any little bit makes a difference. Some simple examples: > > > > * Garbage collection > > * vtkDataArrayTemplate::DataChanged() > > * Abundant use of Modified() > > * Progress reporting > > > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > > > I don't agree that misuse of such features would get caught in reviews. > Very few reviewers are conscious of potential performance issues. Because > very few developers are performance conscious at this point (Dave Gobbi > excepted, he writes amazingly fast code, see image reslice). > > > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear guidelines > on what core classes and algorithms can and cannot do. Once the development > community becomes more aware of these issues and our dashboards are able to > catch performance regressions, we can relax some. > > > > Best, > > -berk > > > > > > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. If > it goes in its own header, then the chances of it being confused with > vtkDebugMacro are significantly reduced. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > > I completely agree with David. This is an application support feature. > There are several examples for such features in VTK, including QVTKWidget > or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK > library itself (other than examples and tests) but in VTK-based > applications. They make the life of application developers easier, allow > standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help application > developers. > > > > Andras > > > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com ] > > *Sent:* Friday, December 12, 2014 09:16 > *To:* vtk-developers at vtk.org > *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro that > doesn't require a debug build. In my own apps, I often write app-specific > classes that are derived from vtkObject and this is a macro that I might > use from time to time. Unlike Berk, I'm not all that worried that it might > be abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within VTK > itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, and > one that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific example > for why this is needed. The examples are all from Slicer - which to me says > that they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use it > is dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it > can lead to significant performance issues, specially in multi-threaded > code. As it is, there are lot of minor issues like this that we will have > to go and clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Sat Dec 20 20:57:39 2014 From: lasso at queensu.ca (Andras Lasso) Date: Sun, 21 Dec 2014 01:57:39 +0000 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Thanks to all for taking time to consider this. I think in the long term such functionality should be part of VTK, but I understand if there are other priorities now and I don?t want to take more of your time with discussing this one particular issue. I hope this request will be revisited in the future, please keep it in mind when other application support features will be integrated into VTK. I?ve entered a ticket to the issue tracker to make sure it will not be forgotten: http://vtk.org/Bug/view.php?id=15220. Andras From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: Saturday, December 20, 2014 10:49 To: Andras Lasso Cc: David Cole; David Gobbi; Jean-Christophe Fillion-Robin (JChris.FillionR at kitware.com); vtk-developers at vtk.org Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" I looked at our current structure and could not find a suitable place that would allow for non-GUI classes to have access to this but not the core classes. It is probably not worth creating a module to just add this header so I recommend keeping it in Slicer for now. Best, -berk On Sat, Dec 13, 2014 at 3:42 PM, Andras Lasso > wrote: You are right, it?s not necessary to make this additional logging macro available for core VTK library modules. It can be anywhere in VTK where VTK tests, examples, and VTK-based applications can access it. Do you have any suggestion for a good place? Having the macro in VTK allows a standardization on the macro name, parameters, and behavior among all VTK-based applications. The macro would be used in application classes derived from vtkObject. Andras From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: Saturday, December 13, 2014 15:16 To: Andras Lasso Cc: David Cole; David Gobbi; Jean-Christophe Fillion-Robin (JChris.FillionR at kitware.com); vtk-developers at vtk.org Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" Sorry but I remain unconvinced. I haven't heard a compelling reason why this functionality should be available to core VTK modules and why the maintainers of those modules need to worry about it. So far, the only example is for a class in Slicer. Whether this is in a separate header or not, putting it in Common/Core will make it possible for all modules in VTK to use this functionality without any compile errors. As I mentioned, I'd like to see functionality migrate out of Common/Core to outer modules not vice versa. "There are other application-only functions in Common already" is not a good reason why we should cram more in there. Also, vtkOutputWindow is used for VTK-level functionality such as debugging and error reporting. Similar to vtkDebugLeaks. I wouldn't call that application specific. Best, -berk On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso > wrote: Yes, sure we don?t need VTK to include a complete logging framework such as log4cpp. We just need a convenient mechanism to send messages to logging frameworks from VTK. What do you think about the following? * Allow completely disable vtkInfoMacro by an #ifdef (for example, if #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can set VTK_INFO_ENABLED to false by default) * Put the macro in a separate header in Common/vtkInfo.h to not make the macro visible to VTK classes by default. GUISupport directory would be too restrictive, as logging is not related to GUI and there are other application-only functions in Common already (such as vtkOutputWindow::DisplayText), but any other suggestion is welcome. Andras From: David Cole [mailto:DLRdave at aol.com] Sent: Saturday, December 13, 2014 09:28 To: David Gobbi Cc: Berk Geveci; vtk-developers at vtk.org; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" I agree with Berk. VTK should NOT include the kitchen sink... This belongs elsewhere -- there are whole separate libraries that are actually focused on logging, and doing it in a high performance, high functionality manner. log4cpp, g2log, and boost all come to mind. Great to hear talk of testing performance regressions on the dashboard -- looking forward to the day that's a reality. Thx, David C. On Friday, December 12, 2014, David Gobbi > wrote: Well, vtkImageReslice is probably not the best "speed" example any more, it has become fat with all the features that I've added to it over the years :) And in the old days, a big reason for its speed was that it did some bit-twiddling to work around the disastrously slow floor() operations on old CPUs. However, it is certainly true with modern computer architectures, with their multiple cores and fast caches, doing _any_ application-level or system-level operations within the algorithmic code causes a significant performance hit, because that takes the CPU core out of the "zone" where it can work at its full potential. - David On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: I'd be fine with it if the header is put into a higher level module such as GUISupport and has some examples demonstrating its purpose and some documentation providing a guide on how to use it. I would not agree to putting this at a place where it may encourage folks to use it in algorithms and other core functionality. As I mentioned previously, I already have the unpleasant job of ripping out a number of "convenience" functionality that are going to have significant impact on performance as we continue to multi-thread more algorithms. All of these features look harmless when initially added. Then they find their way into core functionality slowly but surely. When you are considering 200-way parallelism (which we are, since we are porting to Intel Xeon Phi already), any little bit makes a difference. Some simple examples: * Garbage collection * vtkDataArrayTemplate::DataChanged() * Abundant use of Modified() * Progress reporting Very nice and convenient feature. They may lead to a code running more slowly as more threads are added rather than scale up. I don't agree that misuse of such features would get caught in reviews. Very few reviewers are conscious of potential performance issues. Because very few developers are performance conscious at this point (Dave Gobbi excepted, he writes amazingly fast code, see image reslice). So this is not the time to pepper core classes with convenience functionality. It is time to simplify and come with very clear guidelines on what core classes and algorithms can and cannot do. Once the development community becomes more aware of these issues and our dashboards are able to catch performance regressions, we can relax some. Best, -berk On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: However, I have reservations about putting this macro in vtkSetGet.h. If it goes in its own header, then the chances of it being confused with vtkDebugMacro are significantly reduced. - David On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso > wrote: I completely agree with David. This is an application support feature. There are several examples for such features in VTK, including QVTKWidget or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK library itself (other than examples and tests) but in VTK-based applications. They make the life of application developers easier, allow standardization, reduces code/feature duplication. Adding the macro has negligible impact on VTK but would help application developers. Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, December 12, 2014 09:16 To: vtk-developers at vtk.org Cc: Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso Subject: Re: [vtk-developers] Proposal to add "vtkInfoMacro" On the one hand, I can see that it is useful to have a message macro that doesn't require a debug build. In my own apps, I often write app-specific classes that are derived from vtkObject and this is a macro that I might use from time to time. Unlike Berk, I'm not all that worried that it might be abused. For VTK, we have code review. On the other hand, I don't think we have a use case for this within VTK itself, it would be there purely to serve external VTK classes and apps. And people who need this feature could simply put this macro (or a similar one) in their own header files. Summary: this is a convenience feature, IMHO a mostly harmless one, and one that I might use. - David On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: I disagree with this change. There is no compelling VTK specific example for why this is needed. The examples are all from Slicer - which to me says that they can be implemented in Slicer. Adding a logging functionality without clear guidelines on how to use it is dangerous. It can lead to folks using it for debugging in performance critical sections and since it is not compiled out in Release builds, it can lead to significant performance issues, specially in multi-threaded code. As it is, there are lot of minor issues like this that we will have to go and clean up (progress being one of them). The main use case seems to be tracking interaction/workflow changes. My suggestion is to employ a method appropriate to that. For example, events and listeners. Best, -berk On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin > wrote: Hi Folks, While developing 3D Slicer, we created a macro named vtkInfoMacro similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". We would like to contribute it back to VTK core. The associated topic is: http://review.source.kitware.com/#/c/18385/ It would be great to get feedback before moving forward. Thanks Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sun Dec 21 17:34:27 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sun, 21 Dec 2014 17:34:27 -0500 Subject: [vtk-developers] Proposal to add "vtkInfoMacro" In-Reply-To: References: Message-ID: Thank you Andras. Happy holidays. -berk On Sat, Dec 20, 2014 at 8:57 PM, Andras Lasso wrote: > > Thanks to all for taking time to consider this. I think in the long term > such functionality should be part of VTK, but I understand if there are > other priorities now and I don?t want to take more of your time with > discussing this one particular issue. > > > > I hope this request will be revisited in the future, please keep it in > mind when other application support features will be integrated into VTK. > I?ve entered a ticket to the issue tracker to make sure it will not be > forgotten: http://vtk.org/Bug/view.php?id=15220. > > > > Andras > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* Saturday, December 20, 2014 10:49 > > *To:* Andras Lasso > *Cc:* David Cole; David Gobbi; Jean-Christophe Fillion-Robin ( > JChris.FillionR at kitware.com); vtk-developers at vtk.org > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I looked at our current structure and could not find a suitable place that > would allow for non-GUI classes to have access to this but not the core > classes. It is probably not worth creating a module to just add this header > so I recommend keeping it in Slicer for now. > > > > Best, > > -berk > > > > > > On Sat, Dec 13, 2014 at 3:42 PM, Andras Lasso wrote: > > You are right, it?s not necessary to make this additional logging macro > available for core VTK library modules. It can be anywhere in VTK where VTK > tests, examples, and VTK-based applications can access it. Do you have any > suggestion for a good place? > > > > Having the macro in VTK allows a standardization on the macro name, > parameters, and behavior among all VTK-based applications. The macro would > be used in application classes derived from vtkObject. > > > > Andras > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* Saturday, December 13, 2014 15:16 > *To:* Andras Lasso > *Cc:* David Cole; David Gobbi; Jean-Christophe Fillion-Robin ( > JChris.FillionR at kitware.com); vtk-developers at vtk.org > > > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > Sorry but I remain unconvinced. I haven't heard a compelling reason why > this functionality should be available to core VTK modules and why the > maintainers of those modules need to worry about it. So far, the only > example is for a class in Slicer. > > > > Whether this is in a separate header or not, putting it in Common/Core > will make it possible for all modules in VTK to use this functionality > without any compile errors. As I mentioned, I'd like to see functionality > migrate out of Common/Core to outer modules not vice versa. "There are > other application-only functions in Common already" is not a good reason > why we should cram more in there. Also, vtkOutputWindow is used for > VTK-level functionality such as debugging and error reporting. Similar to > vtkDebugLeaks. I wouldn't call that application specific. > > > > Best, > > -berk > > > > On Sat, Dec 13, 2014 at 11:35 AM, Andras Lasso wrote: > > Yes, sure we don?t need VTK to include a complete logging framework such > as log4cpp. We just need a convenient mechanism to send messages to logging > frameworks from VTK. > > > > What do you think about the following? > > > > * Allow completely disable vtkInfoMacro by an #ifdef (for example, if > #ifndef VTK_INFO_ENABLED then vtkInfoMacro is an empty statement; we can > set VTK_INFO_ENABLED to false by default) > > > > * Put the macro in a separate header in Common/vtkInfo.h to not make the > macro visible to VTK classes by default. GUISupport directory would be too > restrictive, as logging is not related to GUI and there are other > application-only functions in Common already (such as > vtkOutputWindow::DisplayText), but any other suggestion is welcome. > > > > Andras > > > > *From:* David Cole [mailto:DLRdave at aol.com] > *Sent:* Saturday, December 13, 2014 09:28 > *To:* David Gobbi > *Cc:* Berk Geveci; vtk-developers at vtk.org; Andras Lasso > > > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > I agree with Berk. VTK should NOT include the kitchen sink... This belongs > elsewhere -- there are whole separate libraries that are actually focused > on logging, and doing it in a high performance, high functionality manner. > log4cpp, g2log, and boost all come to mind. > > Great to hear talk of testing performance regressions on the dashboard -- > looking forward to the day that's a reality. > > > > Thx, > > David C. > > > > > On Friday, December 12, 2014, David Gobbi wrote: > > Well, vtkImageReslice is probably not the best "speed" example any more, > it has become fat with all the features that I've added to it over the > years :) And in the old days, a big reason for its speed was that it did > some bit-twiddling to work around the disastrously slow floor() operations > on old CPUs. > > > > However, it is certainly true with modern computer architectures, with > their multiple cores and fast caches, doing _any_ application-level or > system-level operations within the algorithmic code causes a significant > performance hit, because that takes the CPU core out of the "zone" where it > can work at its full potential. > > > > - David > > > > On Fri, Dec 12, 2014 at 5:12 PM, Berk Geveci > wrote: > > I'd be fine with it if the header is put into a higher level module such > as GUISupport and has some examples demonstrating its purpose and some > documentation providing a guide on how to use it. I would not agree to > putting this at a place where it may encourage folks to use it in > algorithms and other core functionality. As I mentioned previously, I > already have the unpleasant job of ripping out a number of "convenience" > functionality that are going to have significant impact on performance as > we continue to multi-thread more algorithms. All of these features look > harmless when initially added. Then they find their way into core > functionality slowly but surely. When you are considering 200-way > parallelism (which we are, since we are porting to Intel Xeon Phi already), > any little bit makes a difference. Some simple examples: > > > > * Garbage collection > > * vtkDataArrayTemplate::DataChanged() > > * Abundant use of Modified() > > * Progress reporting > > > > Very nice and convenient feature. They may lead to a code running more > slowly as more threads are added rather than scale up. > > > > I don't agree that misuse of such features would get caught in reviews. > Very few reviewers are conscious of potential performance issues. Because > very few developers are performance conscious at this point (Dave Gobbi > excepted, he writes amazingly fast code, see image reslice). > > > > So this is not the time to pepper core classes with convenience > functionality. It is time to simplify and come with very clear guidelines > on what core classes and algorithms can and cannot do. Once the development > community becomes more aware of these issues and our dashboards are able to > catch performance regressions, we can relax some. > > > > Best, > > -berk > > > > > > > > > > On Fri, Dec 12, 2014 at 9:52 AM, David Gobbi > wrote: > > However, I have reservations about putting this macro in vtkSetGet.h. If > it goes in its own header, then the chances of it being confused with > vtkDebugMacro are significantly reduced. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 7:24 AM, Andras Lasso wrote: > > I completely agree with David. This is an application support feature. > There are several examples for such features in VTK, including QVTKWidget > or vtkOutputWindow::DisplayText(). These are not meant to be used in VTK > library itself (other than examples and tests) but in VTK-based > applications. They make the life of application developers easier, allow > standardization, reduces code/feature duplication. > > > > Adding the macro has negligible impact on VTK but would help application > developers. > > > > Andras > > > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com ] > > *Sent:* Friday, December 12, 2014 09:16 > *To:* vtk-developers at vtk.org > *Cc:* Jean-Christophe Fillion-Robin; Berk Geveci; Andras Lasso > *Subject:* Re: [vtk-developers] Proposal to add "vtkInfoMacro" > > > > On the one hand, I can see that it is useful to have a message macro that > doesn't require a debug build. In my own apps, I often write app-specific > classes that are derived from vtkObject and this is a macro that I might > use from time to time. Unlike Berk, I'm not all that worried that it might > be abused. For VTK, we have code review. > > > > On the other hand, I don't think we have a use case for this within VTK > itself, it would be there purely to serve external VTK classes and apps. > And people who need this feature could simply put this macro (or a similar > one) in their own header files. > > > > Summary: this is a convenience feature, IMHO a mostly harmless one, and > one that I might use. > > > > - David > > > > > > On Fri, Dec 12, 2014 at 6:27 AM, Berk Geveci > wrote: > > I disagree with this change. There is no compelling VTK specific example > for why this is needed. The examples are all from Slicer - which to me says > that they can be implemented in Slicer. > > > > Adding a logging functionality without clear guidelines on how to use it > is dangerous. It can lead to folks using it for debugging in performance > critical sections and since it is not compiled out in Release builds, it > can lead to significant performance issues, specially in multi-threaded > code. As it is, there are lot of minor issues like this that we will have > to go and clean up (progress being one of them). > > > > The main use case seems to be tracking interaction/workflow changes. My > suggestion is to employ a method appropriate to that. For example, events > and listeners. > > > > Best, > > -berk > > > > > > On Thu, Dec 11, 2014 at 12:06 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > > Hi Folks, > > While developing 3D Slicer, we created a macro named > > vtkInfoMacro > > similar to "vtkErrorMacro/vtkDebugMacro/vtkWarningMacro". > > We would like to contribute it back to VTK core. > > > > The associated topic is: > > http://review.source.kitware.com/#/c/18385/ > > It would be great to get feedback before moving forward. > > Thanks > > Jc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karasevpa at gmail.com Mon Dec 22 12:32:01 2014 From: karasevpa at gmail.com (Peter Karasev) Date: Mon, 22 Dec 2014 09:32:01 -0800 Subject: [vtk-developers] material files patch for vtkOBJReader Message-ID: Hi, I'm hoping to get an update for vtkOBJReader integrated in that enables reading material-texture-library (.mtl) files. These are typically distributed along with the .obj file that contains geometry data. There's an issue with the module structure of VTK in doing this, however: having the MTL file means that you basically must generate not only geometry but the entire actors with vtkProperty*'s set on them. I propose moving vtkOBJReader into the same area as vtk3DSImporter, where it is allowed to access things in vtkRenderingCore like vtkActor class. Alternatively, a dependency(ies) could be added to vtkIOGeometry to allow creating actors. Any views on which way to go here? -- _______________ Peter Karasev karasevpa at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Dec 22 14:44:40 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 22 Dec 2014 14:44:40 -0500 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: My preference would be to develop a new OBJ importer that uses the OBJ reader. Making the OBJ reader depend on rendering may impact some folks negatively. By the way, I would defer this for a few months if possible. We have a project targeted towards importing material properties for ray tracing etc. I don't think that we will follow the importer route and we will probably develop a new infrastructure. It may fit better here. Best, -berk On Mon, Dec 22, 2014 at 12:32 PM, Peter Karasev wrote: > > Hi, > > I'm hoping to get an update for vtkOBJReader integrated in that > enables reading material-texture-library (.mtl) files. These are typically > distributed along with the .obj file that contains geometry data. > > There's an issue with the module structure of VTK in doing this, > however: having the MTL file means that you basically must generate not > only geometry but the entire actors with vtkProperty*'s set on them. > > I propose moving vtkOBJReader into the same area as vtk3DSImporter, > where it is allowed to access things in vtkRenderingCore like vtkActor > class. Alternatively, a dependency(ies) could be added to vtkIOGeometry > to allow creating actors. Any views on which way to go here? > > -- > > _______________ > Peter Karasev > karasevpa at gmail.com > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weifeng0715 at gmail.com Mon Dec 22 15:08:46 2014 From: weifeng0715 at gmail.com (weifeng0715) Date: Mon, 22 Dec 2014 13:08:46 -0700 (MST) Subject: [vtk-developers] Need a Consultant In-Reply-To: <1419274447443-5729945.post@n5.nabble.com> References: <1419274447443-5729945.post@n5.nabble.com> Message-ID: Dear Sir/Madam, Could you send me the description of the project first? I'd like to help you. Thanks, Feng On Mon, Dec 22, 2014 at 1:54 PM, harshiloza [via VTK] < ml-node+s1045678n5729945h44 at n5.nabble.com> wrote: > We are developing a software that needs plenty of mesh editing operation. > So far we have explored VTK's Boolean and mesh cutting functionality but > it's quite slow and sometime it produce non-manifold triangulation. > Due to time constrain we need our job to be done at earliest so we are > looking for a *consultant *who has decent experience of working with VTK > liabray and help us in Mesh editing operation. We are willing to pay for > the services. You can also write an e-mail on : nilesh at perennialsys.com. > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://vtk.1045678.n5.nabble.com/Need-a-Consultant-tp5729945.html > To start a new topic under VTK - Dev, email > ml-node+s1045678n1251487h46 at n5.nabble.com > To unsubscribe from VTK - Dev, click here > > . > NAML > > -- Feng Wei Skype : weifeng0715 (preferred) -- View this message in context: http://vtk.1045678.n5.nabble.com/Need-a-Consultant-tp5729945p5729947.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lifestudent37 at gmail.com Tue Dec 30 13:27:36 2014 From: lifestudent37 at gmail.com (Student Life) Date: Tue, 30 Dec 2014 18:27:36 +0000 Subject: [vtk-developers] How do interact with multiple actors independently in a render window? Message-ID: Hi, Basically, I have multiple actors in my render window, and so far if I rotate one actor all the actors move with it as well. I want to interact with multiple objects independently. For example, if I have 5 objects in a render window, I want to only move, rotate and interact with the one selected object; whilst the rest of the 4 objects stay where it is. At the moment, the camera is doing the magic and as I rotate the independent object, other objects move at the same time and I don't want that to happen. I also want to store all the objects in memory. I intend to use C++. This is my sort of class structure... class ScreenObjects{ vtkActor (LinkedList); // I intend on using a linkedlist to store all the actors public: ScreenObjects(); // Constructor. Initializes vtkActor to null. void readSTLFile(); // Reads the STL File bool setObject(); // Sets current object, so you can only interact with the selected object} I am missing quite a lot of functions and detail in my class, as I don't know what else to include that would be of use. I was also thinking of joining two objects together, but again, I don't know how to incorporate that in my class; any information on that would be appreciated. Would really appreciate it if I could be given ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Dec 30 13:34:16 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 Dec 2014 13:34:16 -0500 Subject: [vtk-developers] How do interact with multiple actors independently in a render window? In-Reply-To: References: Message-ID: <35F93A84-A57F-497F-AB66-9168A85F66F2@kitware.com> Hi there Mr. Life, > Basically, I have multiple actors in my render window, and so far if I rotate one actor all the actors move with it as well. Actually what you are doing is interacting with the camera, not the actors. > I want to interact with multiple objects independently. For example, if I have 5 objects in a render window, I want to only move, rotate and interact with the one selected object; whilst the rest of the 4 objects stay where it is. Pressing the 'a' key while the render window is in focus should switch you to transforming actors instead of the camera. Pressing 'c' will switch back to the camera. David From dmsurti at gmail.com Sun Dec 14 09:55:04 2014 From: dmsurti at gmail.com (Deepak Surti) Date: Sun, 14 Dec 2014 14:55:04 -0000 Subject: [vtk-developers] Building VTK with Python Wrapping on Cent OS 5.11 64 bit fails In-Reply-To: References: Message-ID: Hi David, I have attached the CMakeCache.txt and CMakeError.log files. This is while trying to build VTK 6.1 on Cent OS 5.11 64 bit under VMWare. Also, as Mesa 3D OpenGL version is 1.2, will OpenGL2 support be even possible for VTK on Cent OS 5.11 ? Thanks, Deepak On Sun, Dec 14, 2014 at 7:50 PM, David Gobbi wrote: > > Hi Deepak, > > Even though CentOS 5.11 isn't on the dashboard, it should definitely work. > You might be missing one or more .rpm package that is necessary for VTK. > Python wrapping requires BUILD_SHARED_LIBS=ON. > > Please copy the error to your email, because that will give us some clues > as to why the build fails. > > - David > > > On Sun, Dec 14, 2014 at 5:44 AM, Deepak Surti wrote: >> >> Hi, >> >> I am trying to get a VTK build working with Python Wrapping on Cent OS >> 5.11 64 bit. >> >> I have not been able to build any of VTK 5.10, VTK 6.1 or VTK from >> master/nightly branch. The build fails in a different target, for each >> version. Say if I turn off BUILD_SHARED_STATIC_LIBS == OFF, then VTK master >> build fails in target vtkproj4. I also realized that Mesa OpenGL version = >> 1.2, so OpenLG2 rendering support will not likely work for this build. >> >> My specific questions are: >> >> 1. Is Cent OS 5.11 platform supported for VTK? If yes, upto which version? >> 2. Will OpenGL2 rendering be possible on Cent OS 5.11? >> >> I also checked VTK CDash dashboard ( >> https://open.cdash.org/index.php?project=VTK), but do not see Cent OS >> 5.11 as a tested platform. >> >> Any info/suggestions/questions welcome and helpful. >> >> Thanks, >> Deepak >> > -- http://deepaksurti.com To see a miracle, be the miracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0 # It was generated by CMake: /home/deepaksurti/Enthought/Canopy_64bit/User/bin/cmake # 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 the VTK documentation BUILD_DOCUMENTATION:BOOL=OFF //Build VTK examples. BUILD_EXAMPLES:BOOL=OFF //Build Shared Libraries BUILD_SHARED_LIBS:BOOL=ON //Build the testing tree. BUILD_TESTING:BOOL=OFF //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //Choose the type of build. CMAKE_BUILD_TYPE:STRING=Debug //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING='-O2 -pipe -fomit-frame-pointer ' //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler. CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING='-O2 -pipe -fomit-frame-pointer ' //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= -Wl,-R,/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Enable/Disable output of compile commands during generation. CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF //No help, variable specified on the command line. CMAKE_INSTALL_PREFIX:PATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/usr //Path to a program. CMAKE_LINKER:FILEPATH=/usr/bin/ld //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/gmake //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= -Wl,-R,/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_NM:FILEPATH=/usr/bin/nm //Path to a program. CMAKE_OBJCOPY:FILEPATH=/usr/bin/objcopy //Path to a program. CMAKE_OBJDUMP:FILEPATH=/usr/bin/objdump //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=VTK //Path to a program. CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= -Wl,-R,/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD/PLACEHOLD //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=NO //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=NO //Flags used by the linker during the creation of static libraries. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_STRIP:FILEPATH=/usr/bin/strip //Thread library used. CMAKE_THREAD_LIBS:STRING=-lpthread //If true, cmake will use relative paths in makefiles and projects. CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //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=FALSE //Value Computed by CMake DICOMParser_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/DICOMParser //Value Computed by CMake DICOMParser_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/DICOMParser //Path to a library. EXECINFO_LIB:FILEPATH=EXECINFO_LIB-NOTFOUND //Disable compiler warnings EXODUSII_DISABLE_COMPILER_WARNINGS:BOOL=ON //Additional URL templates for the ExternalData CMake script to // look for testing data. E.g. //\nfile:///var/bigharddrive/%(algo)/%(hash) ExternalData_URL_TEMPLATES:STRING= //Value Computed by CMake HDF5_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5 //Value Computed by CMake HDF5_HL_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl //Value Computed by CMake HDF5_HL_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl //Value Computed by CMake HDF5_HL_SRC_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl/src //Value Computed by CMake HDF5_HL_SRC_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl/src //Value Computed by CMake HDF5_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5 //Value Computed by CMake HDF5_SRC_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/src //Value Computed by CMake HDF5_SRC_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/src //Value Computed by CMake JsonCpp_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/jsoncpp/vtkjsoncpp //Value Computed by CMake JsonCpp_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/jsoncpp/vtkjsoncpp //Request building AutobahnPython Module_AutobahnPython:BOOL=OFF //Request building Twisted Module_Twisted:BOOL=OFF //Request building ZopeInterface Module_ZopeInterface:BOOL=OFF //Request building vtkAcceleratorsDax Module_vtkAcceleratorsDax:BOOL=OFF //Request building vtkAcceleratorsPiston Module_vtkAcceleratorsPiston:BOOL=OFF //Request building vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths:BOOL=OFF //Request building vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry:BOOL=OFF //Request building vtkFiltersParallelMPI Module_vtkFiltersParallelMPI:BOOL=OFF //Request building vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics:BOOL=OFF //Request building vtkFiltersReebGraph Module_vtkFiltersReebGraph:BOOL=OFF //Request building vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR:BOOL=OFF //Request building vtkGUISupportQt Module_vtkGUISupportQt:BOOL=OFF //Request building vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL:BOOL=OFF //Request building vtkGUISupportQtSQL Module_vtkGUISupportQtSQL:BOOL=OFF //Request building vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit:BOOL=OFF //Request building vtkIOFFMPEG Module_vtkIOFFMPEG:BOOL=OFF //Request building vtkIOGDAL Module_vtkIOGDAL:BOOL=OFF //Request building vtkIOGeoJSON Module_vtkIOGeoJSON:BOOL=OFF //Request building vtkIOMPIImage Module_vtkIOMPIImage:BOOL=OFF //Request building vtkIOMPIParallel Module_vtkIOMPIParallel:BOOL=OFF //Request building vtkIOMySQL Module_vtkIOMySQL:BOOL=OFF //Request building vtkIOODBC Module_vtkIOODBC:BOOL=OFF //Request building vtkIOParallelExodus Module_vtkIOParallelExodus:BOOL=OFF //Request building vtkIOParallelLSDyna Module_vtkIOParallelLSDyna:BOOL=OFF //Request building vtkIOParallelNetCDF Module_vtkIOParallelNetCDF:BOOL=OFF //Request building vtkIOPostgreSQL Module_vtkIOPostgreSQL:BOOL=OFF //Request building vtkIOVPIC Module_vtkIOVPIC:BOOL=OFF //Request building vtkIOXdmf2 Module_vtkIOXdmf2:BOOL=OFF //Request building vtkInfovisBoost Module_vtkInfovisBoost:BOOL=OFF //Request building vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms:BOOL=OFF //Request building vtkInfovisParallel Module_vtkInfovisParallel:BOOL=OFF //Request building vtkParallelMPI Module_vtkParallelMPI:BOOL=OFF //Request building vtkPythonInterpreter Module_vtkPythonInterpreter:BOOL=OFF //Request building vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig:BOOL=OFF //Request building vtkRenderingMatplotlib Module_vtkRenderingMatplotlib:BOOL=OFF //Request building vtkRenderingParallel Module_vtkRenderingParallel:BOOL=OFF //Request building vtkRenderingParallelLIC Module_vtkRenderingParallelLIC:BOOL=OFF //Request building vtkRenderingQt Module_vtkRenderingQt:BOOL=OFF //Request building vtkRenderingTk Module_vtkRenderingTk:BOOL=OFF //Request building vtkTclTk Module_vtkTclTk:BOOL=OFF //Request building vtkTestingCore Module_vtkTestingCore:BOOL=OFF //Request building vtkTestingGenericBridge Module_vtkTestingGenericBridge:BOOL=OFF //Request building vtkTestingIOSQL Module_vtkTestingIOSQL:BOOL=OFF //Request building vtkTestingRendering Module_vtkTestingRendering:BOOL=OFF //Request building vtkVPIC Module_vtkVPIC:BOOL=OFF //Request building vtkViewsQt Module_vtkViewsQt:BOOL=OFF //Request building vtkWebApplications Module_vtkWebApplications:BOOL=OFF //Request building vtkWebCore Module_vtkWebCore:BOOL=OFF //Request building vtkWebGLExporter Module_vtkWebGLExporter:BOOL=OFF //Request building vtkWebInstall Module_vtkWebInstall:BOOL=OFF //Request building vtkWebJavaScript Module_vtkWebJavaScript:BOOL=OFF //Request building vtkWebPython Module_vtkWebPython:BOOL=OFF //Request building vtkWrappingJava Module_vtkWrappingJava:BOOL=OFF //Request building vtkWrappingPythonCore Module_vtkWrappingPythonCore:BOOL=ON //Request building vtkWrappingTcl Module_vtkWrappingTcl:BOOL=OFF //Request building vtkmrmpi Module_vtkmrmpi:BOOL=OFF //Request building vtkxdmf2 Module_vtkxdmf2:BOOL=OFF //Specify default maximum number of elements in the file chunk // cache chunk for HDF5 files (should be prime number). NETCDF4_CHUNK_CACHE_NELEMS:STRING=1009 //Specify default file chunk cache preemption policy for HDF5 files // (a number between 0 and 1, inclusive). NETCDF4_CHUNK_CACHE_PREEMPTION:STRING=0.75 //Specify default file cache chunk size for HDF5 files in bytes. NETCDF4_CHUNK_CACHE_SIZE:STRING=4194304 //Specify the number of chunks to store in default per-variable // cache. NETCDF4_DEFAULT_CHUNKS_IN_CACHE:STRING=10 //Specify default size of chunks in bytes. NETCDF4_DEFAULT_CHUNK_SIZE:STRING=4194304 //Specify maximum size (in bytes) for the default per-var chunk // cache. NETCDF4_MAX_DEFAULT_CACHE_SIZE:STRING=67108864 //Disable compiler warnings NETCDF_DISABLE_COMPILER_WARNINGS:BOOL=ON //Build netcdf C++ API NETCDF_ENABLE_CXX:BOOL=ON //Path to NVCONTROL headers (NVCtrlLib.h and NVCtrl.h) NVCtrlLib_INCLUDE_DIR:PATH=NVCtrlLib_INCLUDE_DIR-NOTFOUND //Path to NVCONTROL static library (libXNVCtrl.a) NVCtrlLib_LIBRARY:FILEPATH=NVCtrlLib_LIBRARY-NOTFOUND //No help, variable specified on the command line. OPENGL_INCLUDE_DIR:PATH=/usr/include //No help, variable specified on the command line. OPENGL_gl_LIBRARY:PATH=/usr/lib64/libGL.so //No help, variable specified on the command line. OPENGL_glu_LIBRARY:PATH=/usr/lib64/libGLU.so //Path to a file. OPENGL_xmesa_INCLUDE_DIR:PATH=/usr/include //Does an external project define proj_list or should libproj4 // define it? PROJ_LIST_EXTERNAL:BOOL=OFF //Should libproj4 include projection code that relies on GSL? PROJ_USE_GSL:BOOL=OFF //Should libproj4 be built as a thread-friendly library? PROJ_USE_PTHREADS:BOOL=ON //No help, variable specified on the command line. PYTHON_EXECUTABLE:FILEPATH=/home/deepaksurti/Enthought/Canopy_64bit/User/bin/python //No help, variable specified on the command line. PYTHON_EXTRA_LIBS:STRING=-lpthread -ldl -lutil //No help, variable specified on the command line. PYTHON_INCLUDE_DIR:PATH=/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/include/python2.7 //No help, variable specified on the command line. PYTHON_LIBRARY:FILEPATH=/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/lib/python2.7/config/libpython2.7.so //Utility library needed for vtkpython PYTHON_UTIL_LIBRARY:FILEPATH=/usr/lib64/libutil.so //No help, variable specified on the command line. TCL_INCLUDE_PATH:PATH=/home/deepaksurti/Enthought/Canopy_64bit/User/include //No help, variable specified on the command line. TK_INCLUDE_PATH:PATH=/home/deepaksurti/Enthought/Canopy_64bit/User/include //Value Computed by CMake VTKEXPAT_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKEXPAT_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKFREETYPE_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/freetype/vtkfreetype //Value Computed by CMake VTKFREETYPE_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/freetype/vtkfreetype //Value Computed by CMake VTKFTGL_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/ftgl //Value Computed by CMake VTKFTGL_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/ftgl //Value Computed by CMake VTKGL2PS_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/gl2ps/vtkgl2ps //Value Computed by CMake VTKGL2PS_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/gl2ps/vtkgl2ps //Value Computed by CMake VTKJPEG_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKJPEG_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKNETCDF_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf //Value Computed by CMake VTKNETCDF_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf //Value Computed by CMake VTKOGGTHEORA_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/oggtheora/vtkoggtheora //Disable assemby optimizations VTKOGGTHEORA_DISABLE_ASM:BOOL=OFF //Disable the use of floating point code in theora VTKOGGTHEORA_DISABLE_FLOAT:BOOL=OFF //Additional linker flags for vtkoggtheora when building as a shared // library VTKOGGTHEORA_SHARED_LINKER_FLAGS:STRING=-Wl,--version-script="/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/oggtheora/vtkoggtheora/vtkoggtheora.vscript" //Value Computed by CMake VTKOGGTHEORA_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/oggtheora/vtkoggtheora //Value Computed by CMake VTKPNG_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/png/vtkpng //Value Computed by CMake VTKPNG_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/png/vtkpng //Value Computed by CMake VTKSQLite_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/sqlite/vtksqlite //Value Computed by CMake VTKSQLite_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/sqlite/vtksqlite //Value Computed by CMake VTKTIFF_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKTIFF_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKZLIB_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/zlib/vtkzlib //Value Computed by CMake VTKZLIB_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/zlib/vtkzlib //Build all vtkObject derived classes with object factory new methods. VTK_ALL_NEW_OBJECT_FACTORY:BOOL=OFF //Value Computed by CMake VTK_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0 //Request to build all modules VTK_BUILD_ALL_MODULES:BOOL=OFF //Directory where python modules will be built VTK_BUILD_PYTHON_MODULE_DIR:PATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Wrapping/Python //Local directory holding ExternalData objects in the layout %(algo)/%(hash). VTK_DATA_STORE:PATH= //Build leak checking support into VTK. VTK_DEBUG_LEAKS:BOOL=OFF //Add compiler flags to do stricter checking when building debug. VTK_EXTRA_COMPILER_WARNINGS:BOOL=OFF //Location of the OpenGL extensions header file (glext.h). VTK_GLEXT_FILE:FILEPATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/ParseOGLExt/headers/glext.h //Location of the GLX extensions header file (glxext.h). VTK_GLXEXT_FILE:FILEPATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/ParseOGLExt/headers/glxext.h //Request building Imaging modules VTK_Group_Imaging:BOOL=OFF //Request building MPI modules VTK_Group_MPI:BOOL=OFF //Request building Qt modules VTK_Group_Qt:BOOL=OFF //Request building Rendering modules VTK_Group_Rendering:BOOL=ON //Request building of all stand alone modules (no external dependencies // required) VTK_Group_StandAlone:BOOL=ON //Request building Tk modules VTK_Group_Tk:BOOL=OFF //Request building Views modules VTK_Group_Views:BOOL=OFF //Request building Web modules VTK_Group_Web:BOOL=OFF //Enable buggy OpenGL drivers for testing. VTK_IGNORE_GLDRIVER_BUGS:BOOL=OFF //Directory where python modules will be installed VTK_INSTALL_PYTHON_MODULE_DIR:PATH=lib/python2.7/site-packages //Remove all legacy code completely. VTK_LEGACY_REMOVE:BOOL=OFF //Silence all legacy code messages. VTK_LEGACY_SILENT:BOOL=OFF //Should all modules build instantiators VTK_MAKE_INSTANTIATORS:BOOL=OFF //Max number of threads vktMultiThreader will allocate. VTK_MAX_THREADS:STRING=64 //The OpenGL library being used supports off screen Mesa calls VTK_OPENGL_HAS_OSMESA:BOOL=ON //Enable OpenGL error check and report VTK_REPORT_OPENGL_ERRORS:BOOL=ON //Which multi-threaded parallelism implementation to use. Options // are Sequential, Simple, Kaapi or TBB VTK_SMP_IMPLEMENTATION_TYPE:STRING=Sequential //Value Computed by CMake VTK_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0 //Build VTK with 64 bit ids VTK_USE_64BIT_IDS:BOOL=ON //Use GCC visibility support if available. VTK_USE_GCC_VISIBILITY:BOOL=OFF //No help, variable specified on the command line. VTK_USE_GL2PS:BOOL=ON //Enable tests requiring "large" data VTK_USE_LARGE_DATA:BOOL=OFF //Use off screen calls by default VTK_USE_OFFSCREEN:BOOL=OFF //No help, variable specified on the command line. VTK_USE_RENDERING:BOOL=ON //No help, variable specified on the command line. VTK_USE_RPATH:BOOL=OFF //Use system-installed EXPAT VTK_USE_SYSTEM_EXPAT:BOOL=OFF //Use system-installed Freetype VTK_USE_SYSTEM_FREETYPE:BOOL=OFF //Use system-installed GL2PS VTK_USE_SYSTEM_GL2PS:BOOL=OFF //Use system-installed HDF5 VTK_USE_SYSTEM_HDF5:BOOL=OFF //Use system-installed JPEG VTK_USE_SYSTEM_JPEG:BOOL=OFF //Use system-installed JsonCpp VTK_USE_SYSTEM_JSONCPP:BOOL=OFF //Use system-installed LIBPROJ4 VTK_USE_SYSTEM_LIBPROJ4:BOOL=OFF //Use system-installed LibXml2 VTK_USE_SYSTEM_LIBXML2:BOOL=OFF //Use system-installed NetCDF VTK_USE_SYSTEM_NETCDF:BOOL=OFF //Use system-installed OGGTHEORA VTK_USE_SYSTEM_OGGTHEORA:BOOL=OFF //Use system-installed PNG VTK_USE_SYSTEM_PNG:BOOL=OFF //Use system-installed TIFF VTK_USE_SYSTEM_TIFF:BOOL=OFF //Use system-installed ZLIB VTK_USE_SYSTEM_ZLIB:BOOL=OFF //Use TDx interaction devices VTK_USE_TDX:BOOL=OFF //Use X for VTK render windows VTK_USE_X:BOOL=ON //Location of the WGL extensions header file (wglext.h). VTK_WGLEXT_FILE:FILEPATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/ParseOGLExt/headers/wglext.h //Path to a file. VTK_WRAP_HINTS:FILEPATH=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Wrapping/Tools/hints //Should VTK Java wrapping be built? VTK_WRAP_JAVA:BOOL=OFF //Should VTK Python wrapping be built? VTK_WRAP_PYTHON:BOOL=ON //Should VTK Tcl wrapping be built? VTK_WRAP_TCL:BOOL=OFF //Path to a file. X11_ICE_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_ICE_LIB:FILEPATH=/usr/lib64/libICE.so //Path to a file. X11_SM_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_SM_LIB:FILEPATH=/usr/lib64/libSM.so //Path to a file. X11_X11_INCLUDE_PATH:PATH=/usr/include //No help, variable specified on the command line. X11_X11_LIB:FILEPATH=/usr/lib64/libX11.so //Path to a file. X11_XRes_INCLUDE_PATH:PATH=X11_XRes_INCLUDE_PATH-NOTFOUND //Path to a library. X11_XRes_LIB:FILEPATH=X11_XRes_LIB-NOTFOUND //Path to a file. X11_XShm_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_XSync_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_XTest_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_XTest_LIB:FILEPATH=X11_XTest_LIB-NOTFOUND //Path to a file. X11_Xaccessrules_INCLUDE_PATH:PATH=X11_Xaccessrules_INCLUDE_PATH-NOTFOUND //Path to a file. X11_Xaccessstr_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xau_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xau_LIB:FILEPATH=/usr/lib64/libXau.so //Path to a file. X11_Xcomposite_INCLUDE_PATH:PATH=X11_Xcomposite_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xcomposite_LIB:FILEPATH=X11_Xcomposite_LIB-NOTFOUND //Path to a file. X11_Xcursor_INCLUDE_PATH:PATH=X11_Xcursor_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xcursor_LIB:FILEPATH=X11_Xcursor_LIB-NOTFOUND //Path to a file. X11_Xdamage_INCLUDE_PATH:PATH=X11_Xdamage_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xdamage_LIB:FILEPATH=X11_Xdamage_LIB-NOTFOUND //Path to a file. X11_Xdmcp_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xdmcp_LIB:FILEPATH=/usr/lib64/libXdmcp.so //No help, variable specified on the command line. X11_Xext_LIB:FILEPATH=/usr/lib64/libXext.so //Path to a file. X11_Xfixes_INCLUDE_PATH:PATH=X11_Xfixes_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xfixes_LIB:FILEPATH=X11_Xfixes_LIB-NOTFOUND //Path to a file. X11_Xft_INCLUDE_PATH:PATH=X11_Xft_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xft_LIB:FILEPATH=X11_Xft_LIB-NOTFOUND //Path to a file. X11_Xi_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xi_LIB:FILEPATH=X11_Xi_LIB-NOTFOUND //Path to a file. X11_Xinerama_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xinerama_LIB:FILEPATH=X11_Xinerama_LIB-NOTFOUND //Path to a file. X11_Xinput_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xinput_LIB:FILEPATH=X11_Xinput_LIB-NOTFOUND //Path to a file. X11_Xkb_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xkbfile_INCLUDE_PATH:PATH=X11_Xkbfile_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xkbfile_LIB:FILEPATH=X11_Xkbfile_LIB-NOTFOUND //Path to a file. X11_Xkblib_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xlib_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xmu_INCLUDE_PATH:PATH=X11_Xmu_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xmu_LIB:FILEPATH=X11_Xmu_LIB-NOTFOUND //Path to a file. X11_Xpm_INCLUDE_PATH:PATH=X11_Xpm_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xpm_LIB:FILEPATH=X11_Xpm_LIB-NOTFOUND //Path to a file. X11_Xrandr_INCLUDE_PATH:PATH=X11_Xrandr_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xrandr_LIB:FILEPATH=X11_Xrandr_LIB-NOTFOUND //Path to a file. X11_Xrender_INCLUDE_PATH:PATH=X11_Xrender_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xrender_LIB:FILEPATH=X11_Xrender_LIB-NOTFOUND //Path to a file. X11_Xscreensaver_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xscreensaver_LIB:FILEPATH=X11_Xscreensaver_LIB-NOTFOUND //Path to a file. X11_Xshape_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xt_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_Xt_LIB:FILEPATH=/usr/lib64/libXt.so //Path to a file. X11_Xutil_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xv_INCLUDE_PATH:PATH=X11_Xv_INCLUDE_PATH-NOTFOUND //Path to a library. X11_Xv_LIB:FILEPATH=X11_Xv_LIB-NOTFOUND //Path to a library. X11_Xxf86misc_LIB:FILEPATH=X11_Xxf86misc_LIB-NOTFOUND //Path to a library. X11_Xxf86vm_LIB:FILEPATH=X11_Xxf86vm_LIB-NOTFOUND //Path to a file. X11_dpms_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_xf86misc_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_xf86vmode_INCLUDE_PATH:PATH=/usr/include //Value Computed by CMake alglib_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/alglib //Value Computed by CMake alglib_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/alglib //Value Computed by CMake libproj4_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/libproj4/vtklibproj4 //Value Computed by CMake libproj4_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/libproj4/vtklibproj4 //Value Computed by CMake netcdf_cxx_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx //Value Computed by CMake netcdf_cxx_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx //Value Computed by CMake netcdf_libdispatch_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch //Value Computed by CMake netcdf_libdispatch_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch //Value Computed by CMake netcdf_liblib_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/liblib //Value Computed by CMake netcdf_liblib_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/liblib //Value Computed by CMake netcdf_libsrc4_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4 //Value Computed by CMake netcdf_libsrc4_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4 //Value Computed by CMake netcdf_libsrc_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc //Value Computed by CMake netcdf_libsrc_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc //Value Computed by CMake verdict_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/verdict/vtkverdict //Dependencies for target verdict_LIB_DEPENDS:STATIC= //Value Computed by CMake verdict_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/verdict/vtkverdict //Dependencies for the target vtkChartsCorePythonD_LIB_DEPENDS:STATIC=general;vtkChartsCore;general;vtkWrappingPythonCore;general;vtkCommonColorPythonD;general;vtkInfovisCorePythonD;general;vtkRenderingContext2DPythonD; //Dependencies for the target vtkChartsCorePython_LIB_DEPENDS:STATIC=general;vtkChartsCorePythonD; //Dependencies for the target vtkChartsCore_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkCommonColor;general;vtkInfovisCore; //Dependencies for the target vtkCommonColorPythonD_LIB_DEPENDS:STATIC=general;vtkCommonColor;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD; //Dependencies for the target vtkCommonColorPython_LIB_DEPENDS:STATIC=general;vtkCommonColorPythonD; //Dependencies for the target vtkCommonColor_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonComputationalGeometryPythonD_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonSystemPythonD; //Dependencies for the target vtkCommonComputationalGeometryPython_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometryPythonD; //Dependencies for the target vtkCommonComputationalGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonSystem; //Dependencies for the target vtkCommonCorePythonD_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkWrappingPythonCore; //Dependencies for the target vtkCommonCorePython_LIB_DEPENDS:STATIC=general;vtkCommonCorePythonD; //Dependencies for the target vtkCommonCore_LIB_DEPENDS:STATIC=general;vtksys;general;-lpthread; //Dependencies for the target vtkCommonDataModelPythonD_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkWrappingPythonCore;general;vtkCommonMathPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkCommonTransformsPythonD; //Dependencies for the target vtkCommonDataModelPython_LIB_DEPENDS:STATIC=general;vtkCommonDataModelPythonD; //Dependencies for the target vtkCommonDataModel_LIB_DEPENDS:STATIC=general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtksys; //Dependencies for the target vtkCommonExecutionModelPythonD_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMiscPythonD; //Dependencies for the target vtkCommonExecutionModelPython_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkCommonExecutionModel_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonMathPythonD_LIB_DEPENDS:STATIC=general;vtkCommonMath;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD; //Dependencies for the target vtkCommonMathPython_LIB_DEPENDS:STATIC=general;vtkCommonMathPythonD; //Dependencies for the target vtkCommonMath_LIB_DEPENDS:STATIC=general;vtkCommonCore; //Dependencies for the target vtkCommonMiscPythonD_LIB_DEPENDS:STATIC=general;vtkCommonMisc;general;vtkWrappingPythonCore;general;vtkCommonMathPythonD; //Dependencies for the target vtkCommonMiscPython_LIB_DEPENDS:STATIC=general;vtkCommonMiscPythonD; //Dependencies for the target vtkCommonMisc_LIB_DEPENDS:STATIC=general;vtkCommonMath; //Dependencies for the target vtkCommonSystemPythonD_LIB_DEPENDS:STATIC=general;vtkCommonSystem;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD; //Dependencies for the target vtkCommonSystemPython_LIB_DEPENDS:STATIC=general;vtkCommonSystemPythonD; //Dependencies for the target vtkCommonSystem_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtksys; //Dependencies for the target vtkCommonTransformsPythonD_LIB_DEPENDS:STATIC=general;vtkCommonTransforms;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD;general;vtkCommonMathPythonD; //Dependencies for the target vtkCommonTransformsPython_LIB_DEPENDS:STATIC=general;vtkCommonTransformsPythonD; //Dependencies for the target vtkCommonTransforms_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkCommonMath; //Dependencies for target vtkDICOMParser_LIB_DEPENDS:STATIC= //Dependencies for the target vtkDomainsChemistryPythonD_LIB_DEPENDS:STATIC=general;vtkDomainsChemistry;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkFiltersSourcesPythonD;general;vtkIOXMLPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkDomainsChemistryPython_LIB_DEPENDS:STATIC=general;vtkDomainsChemistryPythonD; //Dependencies for the target vtkDomainsChemistry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkRenderingCore;general;vtkIOXML;general;vtkFiltersSources; //Value Computed by CMake vtkExodus2_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/exodusII/vtkexodusII //Value Computed by CMake vtkExodus2_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/exodusII/vtkexodusII //Dependencies for the target vtkFiltersAMRPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD;general;vtkParallelCorePythonD; //Dependencies for the target vtkFiltersAMRPython_LIB_DEPENDS:STATIC=general;vtkFiltersAMRPythonD; //Dependencies for the target vtkFiltersAMR_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkParallelCore; //Dependencies for the target vtkFiltersCorePythonD_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkCommonTransformsPythonD; //Dependencies for the target vtkFiltersCorePython_LIB_DEPENDS:STATIC=general;vtkFiltersCorePythonD; //Dependencies for the target vtkFiltersCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkFiltersExtractionPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersExtraction;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkFiltersCorePythonD;general;vtkFiltersGeneralPythonD;general;vtkFiltersStatisticsPythonD; //Dependencies for the target vtkFiltersExtractionPython_LIB_DEPENDS:STATIC=general;vtkFiltersExtractionPythonD; //Dependencies for the target vtkFiltersExtraction_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkFiltersStatistics; //Dependencies for the target vtkFiltersFlowPathsPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersFlowPaths;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkFiltersGeneralPythonD;general;vtkFiltersSourcesPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkFiltersFlowPathsPython_LIB_DEPENDS:STATIC=general;vtkFiltersFlowPathsPythonD; //Dependencies for the target vtkFiltersFlowPaths_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersGeneral;general;vtkFiltersSources;general;vtkIOCore; //Dependencies for the target vtkFiltersGeneralPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkWrappingPythonCore;general;vtkCommonComputationalGeometryPythonD;general;vtkFiltersCorePythonD; //Dependencies for the target vtkFiltersGeneralPython_LIB_DEPENDS:STATIC=general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkFiltersGeneral_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersCore; //Dependencies for the target vtkFiltersGenericPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersGeneric;general;vtkWrappingPythonCore;general;vtkFiltersCorePythonD;general;vtkFiltersSourcesPythonD; //Dependencies for the target vtkFiltersGenericPython_LIB_DEPENDS:STATIC=general;vtkFiltersGenericPythonD; //Dependencies for the target vtkFiltersGeneric_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkFiltersSources; //Dependencies for the target vtkFiltersGeometryPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersGeometry;general;vtkWrappingPythonCore;general;vtkFiltersCorePythonD; //Dependencies for the target vtkFiltersGeometryPython_LIB_DEPENDS:STATIC=general;vtkFiltersGeometryPythonD; //Dependencies for the target vtkFiltersGeometry_LIB_DEPENDS:STATIC=general;vtkFiltersCore; //Dependencies for the target vtkFiltersHybridPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersHybrid;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD;general;vtkImagingSourcesPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkFiltersHybridPython_LIB_DEPENDS:STATIC=general;vtkFiltersHybridPythonD; //Dependencies for the target vtkFiltersHybrid_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkImagingSources;general;vtkRenderingCore; //Dependencies for the target vtkFiltersHyperTreePythonD_LIB_DEPENDS:STATIC=general;vtkFiltersHyperTree;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkFiltersHyperTreePython_LIB_DEPENDS:STATIC=general;vtkFiltersHyperTreePythonD; //Dependencies for the target vtkFiltersHyperTree_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersImagingPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersImaging;general;vtkWrappingPythonCore;general;vtkFiltersStatisticsPythonD;general;vtkImagingGeneralPythonD;general;vtkImagingSourcesPythonD; //Dependencies for the target vtkFiltersImagingPython_LIB_DEPENDS:STATIC=general;vtkFiltersImagingPythonD; //Dependencies for the target vtkFiltersImaging_LIB_DEPENDS:STATIC=general;vtkFiltersStatistics;general;vtkImagingGeneral;general;vtkImagingSources; //Dependencies for the target vtkFiltersModelingPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersModeling;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD;general;vtkFiltersSourcesPythonD; //Dependencies for the target vtkFiltersModelingPython_LIB_DEPENDS:STATIC=general;vtkFiltersModelingPythonD; //Dependencies for the target vtkFiltersModeling_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkFiltersSources; //Dependencies for the target vtkFiltersParallelImagingPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersParallelImaging;general;vtkWrappingPythonCore;general;vtkFiltersImagingPythonD;general;vtkFiltersParallelPythonD;general;vtkIOLegacyPythonD;general;vtkImagingCorePythonD;general;vtkParallelCorePythonD; //Dependencies for the target vtkFiltersParallelImagingPython_LIB_DEPENDS:STATIC=general;vtkFiltersParallelImagingPythonD; //Dependencies for the target vtkFiltersParallelImaging_LIB_DEPENDS:STATIC=general;vtkFiltersImaging;general;vtkFiltersParallel;general;vtkIOLegacy;general;vtkImagingCore;general;vtkParallelCore; //Dependencies for the target vtkFiltersParallelPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersParallel;general;vtkWrappingPythonCore;general;vtkFiltersExtractionPythonD;general;vtkFiltersGeometryPythonD;general;vtkFiltersModelingPythonD;general;vtkParallelCorePythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkFiltersParallelPython_LIB_DEPENDS:STATIC=general;vtkFiltersParallelPythonD; //Dependencies for the target vtkFiltersParallel_LIB_DEPENDS:STATIC=general;vtkFiltersExtraction;general;vtkFiltersGeometry;general;vtkFiltersModeling;general;vtkParallelCore;general;vtkRenderingCore; //Dependencies for the target vtkFiltersProgrammablePythonD_LIB_DEPENDS:STATIC=general;vtkFiltersProgrammable;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkFiltersProgrammablePython_LIB_DEPENDS:STATIC=general;vtkFiltersProgrammablePythonD; //Dependencies for the target vtkFiltersProgrammable_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel; //Dependencies for the target vtkFiltersSMPPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersSMP;general;vtkWrappingPythonCore;general;vtkFiltersCorePythonD;general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkFiltersSMPPython_LIB_DEPENDS:STATIC=general;vtkFiltersSMPPythonD; //Dependencies for the target vtkFiltersSMP_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersSelectionPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersSelection;general;vtkWrappingPythonCore;general;vtkCommonComputationalGeometryPythonD;general;vtkFiltersCorePythonD; //Dependencies for the target vtkFiltersSelectionPython_LIB_DEPENDS:STATIC=general;vtkFiltersSelectionPythonD; //Dependencies for the target vtkFiltersSelection_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersCore; //Dependencies for the target vtkFiltersSourcesPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersSources;general;vtkWrappingPythonCore;general;vtkCommonComputationalGeometryPythonD;general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkFiltersSourcesPython_LIB_DEPENDS:STATIC=general;vtkFiltersSourcesPythonD; //Dependencies for the target vtkFiltersSources_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersStatisticsPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersStatistics;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonMiscPythonD;general;vtkCommonTransformsPythonD;general;vtkImagingFourierPythonD; //Dependencies for the target vtkFiltersStatisticsPython_LIB_DEPENDS:STATIC=general;vtkFiltersStatisticsPythonD; //Dependencies for the target vtkFiltersStatistics_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonTransforms;general;vtkImagingFourier;general;vtkalglib; //Dependencies for the target vtkFiltersTexturePythonD_LIB_DEPENDS:STATIC=general;vtkFiltersTexture;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkFiltersTexturePython_LIB_DEPENDS:STATIC=general;vtkFiltersTexturePythonD; //Dependencies for the target vtkFiltersTexture_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersVerdictPythonD_LIB_DEPENDS:STATIC=general;vtkFiltersVerdict;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkFiltersVerdictPython_LIB_DEPENDS:STATIC=general;vtkFiltersVerdictPythonD; //Dependencies for the target vtkFiltersVerdict_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;verdict; //Dependencies for the target vtkGeovisCorePythonD_LIB_DEPENDS:STATIC=general;vtkGeovisCore;general;vtkWrappingPythonCore;general;vtkIOXMLPythonD;general;vtkInfovisLayoutPythonD;general;vtkInteractionStylePythonD;general;vtkInteractionWidgetsPythonD;general;vtkRenderingOpenGLPythonD;general;vtkViewsCorePythonD; //Dependencies for the target vtkGeovisCorePython_LIB_DEPENDS:STATIC=general;vtkGeovisCorePythonD; //Dependencies for the target vtkGeovisCore_LIB_DEPENDS:STATIC=general;vtkIOXML;general;vtkInfovisLayout;general;vtkInteractionStyle;general;vtkInteractionWidgets;general;vtkRenderingOpenGL;general;vtkViewsCore;general;vtkproj4; //Dependencies for the target vtkIOAMRPythonD_LIB_DEPENDS:STATIC=general;vtkIOAMR;general;vtkWrappingPythonCore;general;vtkFiltersAMRPythonD;general;vtkParallelCorePythonD; //Dependencies for the target vtkIOAMRPython_LIB_DEPENDS:STATIC=general;vtkIOAMRPythonD; //Dependencies for the target vtkIOAMR_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkParallelCore;general;vtkhdf5_hl;general;vtkhdf5;general;vtksys; //Dependencies for the target vtkIOCorePythonD_LIB_DEPENDS:STATIC=general;vtkIOCore;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonExecutionModelPythonD;general;vtkCommonMiscPythonD; //Dependencies for the target vtkIOCorePython_LIB_DEPENDS:STATIC=general;vtkIOCorePythonD; //Dependencies for the target vtkIOCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkzlib;general;vtksys; //Dependencies for the target vtkIOEnSightPythonD_LIB_DEPENDS:STATIC=general;vtkIOEnSight;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkIOEnSightPython_LIB_DEPENDS:STATIC=general;vtkIOEnSightPythonD; //Dependencies for the target vtkIOEnSight_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel; //Dependencies for the target vtkIOExodusPythonD_LIB_DEPENDS:STATIC=general;vtkIOExodus;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD;general;vtkIOXMLPythonD; //Dependencies for the target vtkIOExodusPython_LIB_DEPENDS:STATIC=general;vtkIOExodusPythonD; //Dependencies for the target vtkIOExodus_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkIOXML;general;vtkexoIIc;general;vtksys; //Dependencies for the target vtkIOExportPythonD_LIB_DEPENDS:STATIC=general;vtkIOExport;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD;general;vtkFiltersGeometryPythonD;general;vtkIOImagePythonD;general;vtkImagingCorePythonD;general;vtkRenderingAnnotationPythonD;general;vtkRenderingContext2DPythonD;general;vtkRenderingCorePythonD;general;vtkRenderingFreeTypePythonD;general;vtkRenderingGL2PSPythonD;general;vtkRenderingLabelPythonD;general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkIOExportPython_LIB_DEPENDS:STATIC=general;vtkIOExportPythonD; //Dependencies for the target vtkIOExport_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkImagingCore;general;vtkRenderingAnnotation;general;vtkRenderingContext2D;general;vtkRenderingCore;general;vtkRenderingFreeType;general;vtkRenderingGL2PS;general;vtkRenderingLabel;general;vtkRenderingOpenGL;general;vtkIOImage;general;vtkFiltersGeometry;general;vtkgl2ps; //Dependencies for the target vtkIOGeometryPythonD_LIB_DEPENDS:STATIC=general;vtkIOGeometry;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIOGeometryPython_LIB_DEPENDS:STATIC=general;vtkIOGeometryPythonD; //Dependencies for the target vtkIOGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkzlib;general;vtkjsoncpp;general;vtksys; //Dependencies for the target vtkIOImagePythonD_LIB_DEPENDS:STATIC=general;vtkIOImage;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonExecutionModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkCommonTransformsPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIOImagePython_LIB_DEPENDS:STATIC=general;vtkIOImagePythonD; //Dependencies for the target vtkIOImage_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkIOCore;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkmetaio;general;vtkDICOMParser;general;vtksys; //Dependencies for the target vtkIOImportPythonD_LIB_DEPENDS:STATIC=general;vtkIOImport;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD;general;vtkFiltersSourcesPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkIOImportPython_LIB_DEPENDS:STATIC=general;vtkIOImportPythonD; //Dependencies for the target vtkIOImport_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkRenderingCore;general;vtkFiltersSources; //Dependencies for the target vtkIOInfovisPythonD_LIB_DEPENDS:STATIC=general;vtkIOInfovis;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD;general;vtkIOLegacyPythonD;general;vtkInfovisCorePythonD; //Dependencies for the target vtkIOInfovisPython_LIB_DEPENDS:STATIC=general;vtkIOInfovisPythonD; //Dependencies for the target vtkIOInfovis_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkIOLegacy;general;vtkInfovisCore;general;vtklibxml2;general;vtksys; //Dependencies for the target vtkIOLSDynaPythonD_LIB_DEPENDS:STATIC=general;vtkIOLSDyna;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkIOXMLPythonD; //Dependencies for the target vtkIOLSDynaPython_LIB_DEPENDS:STATIC=general;vtkIOLSDynaPythonD; //Dependencies for the target vtkIOLSDyna_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkIOXML;general;vtksys; //Dependencies for the target vtkIOLegacyPythonD_LIB_DEPENDS:STATIC=general;vtkIOLegacy;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIOLegacyPython_LIB_DEPENDS:STATIC=general;vtkIOLegacyPythonD; //Dependencies for the target vtkIOLegacy_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtksys; //Dependencies for the target vtkIOMINCPythonD_LIB_DEPENDS:STATIC=general;vtkIOMINC;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkFiltersHybridPythonD;general;vtkIOGeometryPythonD;general;vtkIOImagePythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkIOMINCPython_LIB_DEPENDS:STATIC=general;vtkIOMINCPythonD; //Dependencies for the target vtkIOMINC_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersHybrid;general;vtkIOGeometry;general;vtkIOImage;general;vtkRenderingCore;general;vtksys;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOMoviePythonD_LIB_DEPENDS:STATIC=general;vtkIOMovie;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonExecutionModelPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIOMoviePython_LIB_DEPENDS:STATIC=general;vtkIOMoviePythonD; //Dependencies for the target vtkIOMovie_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonSystem;general;vtkIOCore;general;vtkoggtheora; //Dependencies for the target vtkIONetCDFPythonD_LIB_DEPENDS:STATIC=general;vtkIONetCDF;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIONetCDFPython_LIB_DEPENDS:STATIC=general;vtkIONetCDFPythonD; //Dependencies for the target vtkIONetCDF_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonSystem;general;vtkIOCore;general;vtksys;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOPLYPythonD_LIB_DEPENDS:STATIC=general;vtkIOPLY;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkCommonMiscPythonD;general;vtkIOGeometryPythonD; //Dependencies for the target vtkIOPLYPython_LIB_DEPENDS:STATIC=general;vtkIOPLYPythonD; //Dependencies for the target vtkIOPLY_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkIOGeometry; //Dependencies for the target vtkIOParallelPythonD_LIB_DEPENDS:STATIC=general;vtkIOParallel;general;vtkWrappingPythonCore;general;vtkFiltersParallelPythonD;general;vtkIOImagePythonD;general;vtkIONetCDFPythonD;general;vtkIOXMLPythonD;general;vtkParallelCorePythonD; //Dependencies for the target vtkIOParallelPython_LIB_DEPENDS:STATIC=general;vtkIOParallelPythonD; //Dependencies for the target vtkIOParallel_LIB_DEPENDS:STATIC=general;vtkFiltersParallel;general;vtkIOImage;general;vtkIONetCDF;general;vtkIOXML;general;vtkParallelCore;general;vtkexoIIc;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOSQLPythonD_LIB_DEPENDS:STATIC=general;vtkIOSQL;general;vtkWrappingPythonCore;general;vtkIOCorePythonD; //Dependencies for the target vtkIOSQLPython_LIB_DEPENDS:STATIC=general;vtkIOSQLPythonD; //Dependencies for the target vtkIOSQL_LIB_DEPENDS:STATIC=general;vtkIOCore;general;vtksys;general;vtksqlite; //Dependencies for the target vtkIOVideoPythonD_LIB_DEPENDS:STATIC=general;vtkIOVideo;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkIOVideoPython_LIB_DEPENDS:STATIC=general;vtkIOVideoPythonD; //Dependencies for the target vtkIOVideo_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtksys; //Dependencies for the target vtkIOXMLParserPythonD_LIB_DEPENDS:STATIC=general;vtkIOXMLParser;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMiscPythonD;general;vtkCommonSystemPythonD;general;vtkIOCorePythonD; //Dependencies for the target vtkIOXMLParserPython_LIB_DEPENDS:STATIC=general;vtkIOXMLParserPythonD; //Dependencies for the target vtkIOXMLParser_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkexpat; //Dependencies for the target vtkIOXMLPythonD_LIB_DEPENDS:STATIC=general;vtkIOXML;general;vtkWrappingPythonCore;general;vtkIOGeometryPythonD;general;vtkIOXMLParserPythonD; //Dependencies for the target vtkIOXMLPython_LIB_DEPENDS:STATIC=general;vtkIOXMLPythonD; //Dependencies for the target vtkIOXML_LIB_DEPENDS:STATIC=general;vtkIOGeometry;general;vtkIOXMLParser;general;vtksys; //Dependencies for the target vtkImagingColorPythonD_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingColorPython_LIB_DEPENDS:STATIC=general;vtkImagingColorPythonD; //Dependencies for the target vtkImagingColor_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingCorePythonD_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonSystemPythonD;general;vtkCommonTransformsPythonD; //Dependencies for the target vtkImagingCorePython_LIB_DEPENDS:STATIC=general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkImagingFourierPythonD_LIB_DEPENDS:STATIC=general;vtkImagingFourier;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingFourierPython_LIB_DEPENDS:STATIC=general;vtkImagingFourierPythonD; //Dependencies for the target vtkImagingFourier_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtksys; //Dependencies for the target vtkImagingGeneralPythonD_LIB_DEPENDS:STATIC=general;vtkImagingGeneral;general;vtkWrappingPythonCore;general;vtkImagingSourcesPythonD; //Dependencies for the target vtkImagingGeneralPython_LIB_DEPENDS:STATIC=general;vtkImagingGeneralPythonD; //Dependencies for the target vtkImagingGeneral_LIB_DEPENDS:STATIC=general;vtkImagingSources; //Dependencies for the target vtkImagingHybridPythonD_LIB_DEPENDS:STATIC=general;vtkImagingHybrid;general;vtkWrappingPythonCore;general;vtkIOImagePythonD;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingHybridPython_LIB_DEPENDS:STATIC=general;vtkImagingHybridPythonD; //Dependencies for the target vtkImagingHybrid_LIB_DEPENDS:STATIC=general;vtkIOImage;general;vtkImagingCore; //Dependencies for the target vtkImagingMathPythonD_LIB_DEPENDS:STATIC=general;vtkImagingMath;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonExecutionModelPythonD; //Dependencies for the target vtkImagingMathPython_LIB_DEPENDS:STATIC=general;vtkImagingMathPythonD; //Dependencies for the target vtkImagingMath_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel; //Dependencies for the target vtkImagingMorphologicalPythonD_LIB_DEPENDS:STATIC=general;vtkImagingMorphological;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD;general;vtkImagingGeneralPythonD; //Dependencies for the target vtkImagingMorphologicalPython_LIB_DEPENDS:STATIC=general;vtkImagingMorphologicalPythonD; //Dependencies for the target vtkImagingMorphological_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkImagingGeneral; //Dependencies for the target vtkImagingSourcesPythonD_LIB_DEPENDS:STATIC=general;vtkImagingSources;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingSourcesPython_LIB_DEPENDS:STATIC=general;vtkImagingSourcesPythonD; //Dependencies for the target vtkImagingSources_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingStatisticsPythonD_LIB_DEPENDS:STATIC=general;vtkImagingStatistics;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingStatisticsPython_LIB_DEPENDS:STATIC=general;vtkImagingStatisticsPythonD; //Dependencies for the target vtkImagingStatistics_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingStencilPythonD_LIB_DEPENDS:STATIC=general;vtkImagingStencil;general;vtkWrappingPythonCore;general;vtkCommonComputationalGeometryPythonD;general;vtkImagingCorePythonD; //Dependencies for the target vtkImagingStencilPython_LIB_DEPENDS:STATIC=general;vtkImagingStencilPythonD; //Dependencies for the target vtkImagingStencil_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkImagingCore; //Dependencies for the target vtkInfovisCorePythonD_LIB_DEPENDS:STATIC=general;vtkInfovisCore;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonSystemPythonD;general;vtkFiltersExtractionPythonD;general;vtkFiltersGeneralPythonD; //Dependencies for the target vtkInfovisCorePython_LIB_DEPENDS:STATIC=general;vtkInfovisCorePythonD; //Dependencies for the target vtkInfovisCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonSystem;general;vtkFiltersExtraction;general;vtkFiltersGeneral; //Dependencies for the target vtkInfovisLayoutPythonD_LIB_DEPENDS:STATIC=general;vtkInfovisLayout;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkFiltersModelingPythonD;general;vtkImagingHybridPythonD;general;vtkInfovisCorePythonD; //Dependencies for the target vtkInfovisLayoutPython_LIB_DEPENDS:STATIC=general;vtkInfovisLayoutPythonD; //Dependencies for the target vtkInfovisLayout_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersModeling;general;vtkImagingHybrid;general;vtkInfovisCore; //Dependencies for the target vtkInteractionImagePythonD_LIB_DEPENDS:STATIC=general;vtkInteractionImage;general;vtkWrappingPythonCore;general;vtkImagingColorPythonD;general;vtkInteractionStylePythonD;general;vtkInteractionWidgetsPythonD;general;vtkRenderingCorePythonD;general;vtkRenderingFreeTypePythonD; //Dependencies for the target vtkInteractionImagePython_LIB_DEPENDS:STATIC=general;vtkInteractionImagePythonD; //Dependencies for the target vtkInteractionImage_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkInteractionStyle;general;vtkInteractionWidgets;general;vtkRenderingCore;general;vtkRenderingFreeType; //Dependencies for the target vtkInteractionStylePythonD_LIB_DEPENDS:STATIC=general;vtkInteractionStyle;general;vtkWrappingPythonCore;general;vtkFiltersExtractionPythonD;general;vtkFiltersSourcesPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkInteractionStylePython_LIB_DEPENDS:STATIC=general;vtkInteractionStylePythonD; //Dependencies for the target vtkInteractionStyle_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkFiltersSources;general;vtkFiltersExtraction; //Dependencies for the target vtkInteractionWidgetsPythonD_LIB_DEPENDS:STATIC=general;vtkInteractionWidgets;general;vtkWrappingPythonCore;general;vtkFiltersHybridPythonD;general;vtkFiltersModelingPythonD;general;vtkImagingGeneralPythonD;general;vtkImagingHybridPythonD;general;vtkInteractionStylePythonD;general;vtkRenderingAnnotationPythonD;general;vtkRenderingFreeTypePythonD;general;vtkRenderingVolumePythonD; //Dependencies for the target vtkInteractionWidgetsPython_LIB_DEPENDS:STATIC=general;vtkInteractionWidgetsPythonD; //Dependencies for the target vtkInteractionWidgets_LIB_DEPENDS:STATIC=general;vtkFiltersHybrid;general;vtkFiltersModeling;general;vtkImagingGeneral;general;vtkImagingHybrid;general;vtkInteractionStyle;general;vtkRenderingAnnotation;general;vtkRenderingFreeType;general;vtkRenderingVolume; //Dependencies for the target vtkNetCDF_LIB_DEPENDS:STATIC=general;vtkhdf5_hl;general;vtkhdf5;general;m; //Dependencies for the target vtkNetCDF_cxx_LIB_DEPENDS:STATIC=general;vtkNetCDF; //Dependencies for the target vtkParallelCorePythonD_LIB_DEPENDS:STATIC=general;vtkParallelCore;general;vtkWrappingPythonCore;general;vtkCommonCorePythonD;general;vtkIOLegacyPythonD; //Dependencies for the target vtkParallelCorePython_LIB_DEPENDS:STATIC=general;vtkParallelCorePythonD; //Dependencies for the target vtkParallelCore_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkIOLegacy;general;vtksys; //Dependencies for the target vtkRenderingAnnotationPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingAnnotation;general;vtkWrappingPythonCore;general;vtkFiltersSourcesPythonD;general;vtkImagingColorPythonD;general;vtkRenderingFreeTypePythonD; //Dependencies for the target vtkRenderingAnnotationPython_LIB_DEPENDS:STATIC=general;vtkRenderingAnnotationPythonD; //Dependencies for the target vtkRenderingAnnotation_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkRenderingFreeType;general;vtkFiltersSources; //Dependencies for the target vtkRenderingContext2DPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkWrappingPythonCore;general;vtkCommonDataModelPythonD;general;vtkCommonMathPythonD;general;vtkCommonTransformsPythonD;general;vtkRenderingCorePythonD;general;vtkRenderingFreeTypePythonD;general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkRenderingContext2DPython_LIB_DEPENDS:STATIC=general;vtkRenderingContext2DPythonD; //Dependencies for the target vtkRenderingContext2D_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonTransforms;general;vtkRenderingOpenGL;general;vtkRenderingFreeType; //Dependencies for the target vtkRenderingCorePythonD_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkWrappingPythonCore;general;vtkCommonExecutionModelPythonD;general;vtkCommonTransformsPythonD;general;vtkFiltersExtractionPythonD;general;vtkFiltersGeometryPythonD;general;vtkFiltersSourcesPythonD; //Dependencies for the target vtkRenderingCorePython_LIB_DEPENDS:STATIC=general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonTransforms;general;vtkFiltersSources;general;vtkFiltersGeometry;general;vtkFiltersExtraction;general;vtksys; //Dependencies for the target vtkRenderingFreeTypeOpenGLPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingFreeTypeOpenGL;general;vtkWrappingPythonCore;general;vtkRenderingCorePythonD;general;vtkRenderingFreeTypePythonD;general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkRenderingFreeTypeOpenGLPython_LIB_DEPENDS:STATIC=general;vtkRenderingFreeTypeOpenGLPythonD; //Dependencies for the target vtkRenderingFreeTypeOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkRenderingFreeType;general;vtkRenderingOpenGL; //Dependencies for the target vtkRenderingFreeTypePythonD_LIB_DEPENDS:STATIC=general;vtkRenderingFreeType;general;vtkWrappingPythonCore;general;vtkRenderingCorePythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingFreeTypePython_LIB_DEPENDS:STATIC=general;vtkRenderingFreeTypePythonD; //Dependencies for the target vtkRenderingFreeType_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkRenderingCore;general;vtkfreetype;general;vtkftgl; //Dependencies for the target vtkRenderingGL2PSPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingGL2PS;general;vtkWrappingPythonCore;general;vtkRenderingContext2DPythonD;general;vtkRenderingFreeTypePythonD;general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkRenderingGL2PSPython_LIB_DEPENDS:STATIC=general;vtkRenderingGL2PSPythonD; //Dependencies for the target vtkRenderingGL2PS_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkRenderingOpenGL;general;vtkRenderingFreeType;general;vtkgl2ps; //Dependencies for the target vtkRenderingImagePythonD_LIB_DEPENDS:STATIC=general;vtkRenderingImage;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingImagePython_LIB_DEPENDS:STATIC=general;vtkRenderingImagePythonD; //Dependencies for the target vtkRenderingImage_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkRenderingCore; //Dependencies for the target vtkRenderingLICPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingLIC;general;vtkWrappingPythonCore;general;vtkIOLegacyPythonD;general;vtkIOXMLPythonD;general;vtkImagingSourcesPythonD;general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkRenderingLICPython_LIB_DEPENDS:STATIC=general;vtkRenderingLICPythonD; //Dependencies for the target vtkRenderingLIC_LIB_DEPENDS:STATIC=general;vtkIOLegacy;general;vtkIOXML;general;vtkImagingSources;general;vtkRenderingOpenGL;general;vtksys; //Dependencies for the target vtkRenderingLODPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingLOD;general;vtkWrappingPythonCore;general;vtkFiltersModelingPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingLODPython_LIB_DEPENDS:STATIC=general;vtkRenderingLODPythonD; //Dependencies for the target vtkRenderingLOD_LIB_DEPENDS:STATIC=general;vtkFiltersModeling;general;vtkRenderingCore; //Dependencies for the target vtkRenderingLabelPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingLabel;general;vtkWrappingPythonCore;general;vtkFiltersExtractionPythonD;general;vtkRenderingFreeTypePythonD; //Dependencies for the target vtkRenderingLabelPython_LIB_DEPENDS:STATIC=general;vtkRenderingLabelPythonD; //Dependencies for the target vtkRenderingLabel_LIB_DEPENDS:STATIC=general;vtkRenderingFreeType;general;vtkFiltersExtraction; //Dependencies for the target vtkRenderingOpenGLPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingOpenGL;general;vtkWrappingPythonCore;general;vtkImagingHybridPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingOpenGLPython_LIB_DEPENDS:STATIC=general;vtkRenderingOpenGLPythonD; //Dependencies for the target vtkRenderingOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkImagingHybrid;general;vtksys;general;/usr/lib64/libGLU.so;general;/usr/lib64/libGL.so;general;/usr/lib64/libSM.so;general;/usr/lib64/libICE.so;general;/usr/lib64/libX11.so;general;/usr/lib64/libXext.so;general;/usr/lib64/libSM.so;general;/usr/lib64/libICE.so;general;/usr/lib64/libX11.so;general;/usr/lib64/libXext.so;general;/usr/lib64/libXt.so; //Dependencies for the target vtkRenderingVolumeAMRPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeAMR;general;vtkWrappingPythonCore;general;vtkFiltersAMRPythonD;general;vtkParallelCorePythonD;general;vtkRenderingVolumePythonD; //Dependencies for the target vtkRenderingVolumeAMRPython_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeAMRPythonD; //Dependencies for the target vtkRenderingVolumeAMR_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkParallelCore;general;vtkRenderingVolume; //Dependencies for the target vtkRenderingVolumeOpenGLPythonD_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeOpenGL;general;vtkWrappingPythonCore;general;vtkFiltersGeneralPythonD;general;vtkFiltersSourcesPythonD;general;vtkRenderingOpenGLPythonD;general;vtkRenderingVolumePythonD; //Dependencies for the target vtkRenderingVolumeOpenGLPython_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeOpenGLPythonD; //Dependencies for the target vtkRenderingVolumeOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingOpenGL;general;vtkRenderingVolume;general;vtksys;general;vtkFiltersGeneral;general;vtkFiltersSources; //Dependencies for the target vtkRenderingVolumePythonD_LIB_DEPENDS:STATIC=general;vtkRenderingVolume;general;vtkWrappingPythonCore;general;vtkImagingCorePythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkRenderingVolumePython_LIB_DEPENDS:STATIC=general;vtkRenderingVolumePythonD; //Dependencies for the target vtkRenderingVolume_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkRenderingCore; //Dependencies for the target vtkViewsContext2DPythonD_LIB_DEPENDS:STATIC=general;vtkViewsContext2D;general;vtkWrappingPythonCore;general;vtkRenderingContext2DPythonD;general;vtkViewsCorePythonD; //Dependencies for the target vtkViewsContext2DPython_LIB_DEPENDS:STATIC=general;vtkViewsContext2DPythonD; //Dependencies for the target vtkViewsContext2D_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkViewsCore; //Dependencies for the target vtkViewsCorePythonD_LIB_DEPENDS:STATIC=general;vtkViewsCore;general;vtkWrappingPythonCore;general;vtkInteractionWidgetsPythonD;general;vtkRenderingCorePythonD; //Dependencies for the target vtkViewsCorePython_LIB_DEPENDS:STATIC=general;vtkViewsCorePythonD; //Dependencies for the target vtkViewsCore_LIB_DEPENDS:STATIC=general;vtkInteractionWidgets;general;vtkRenderingCore; //Dependencies for the target vtkViewsGeovisPythonD_LIB_DEPENDS:STATIC=general;vtkViewsGeovis;general;vtkWrappingPythonCore;general;vtkGeovisCorePythonD;general;vtkViewsInfovisPythonD; //Dependencies for the target vtkViewsGeovisPython_LIB_DEPENDS:STATIC=general;vtkViewsGeovisPythonD; //Dependencies for the target vtkViewsGeovis_LIB_DEPENDS:STATIC=general;vtkGeovisCore;general;vtkViewsInfovis; //Dependencies for the target vtkViewsInfovisPythonD_LIB_DEPENDS:STATIC=general;vtkViewsInfovis;general;vtkWrappingPythonCore;general;vtkChartsCorePythonD;general;vtkCommonColorPythonD;general;vtkFiltersGeometryPythonD;general;vtkFiltersImagingPythonD;general;vtkFiltersModelingPythonD;general;vtkInfovisLayoutPythonD;general;vtkInteractionStylePythonD;general;vtkRenderingContext2DPythonD;general;vtkRenderingLabelPythonD;general;vtkViewsCorePythonD; //Dependencies for the target vtkViewsInfovisPython_LIB_DEPENDS:STATIC=general;vtkViewsInfovisPythonD; //Dependencies for the target vtkViewsInfovis_LIB_DEPENDS:STATIC=general;vtkChartsCore;general;vtkCommonColor;general;vtkFiltersImaging;general;vtkFiltersModeling;general;vtkInfovisLayout;general;vtkInteractionStyle;general;vtkRenderingContext2D;general;vtkRenderingLabel;general;vtkViewsCore;general;vtkFiltersGeometry; //Dependencies for the target vtkWrappingPythonCore_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/lib/python2.7/config/libpython2.7.so;general;vtksys; //Dependencies for target vtkWrappingTools_LIB_DEPENDS:STATIC= //Dependencies for target vtkalglib_LIB_DEPENDS:STATIC= //Dependencies for the target vtkexoIIc_LIB_DEPENDS:STATIC=general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for target vtkexpat_LIB_DEPENDS:STATIC= //Dependencies for the target vtkfreetype_LIB_DEPENDS:STATIC=general;vtkzlib; //Dependencies for the target vtkftgl_LIB_DEPENDS:STATIC=general;/usr/lib64/libGL.so;general;vtkfreetype; //Dependencies for the target vtkgl2ps_LIB_DEPENDS:STATIC=general;/usr/lib64/libGL.so;general;m;general;vtkzlib;general;vtkpng;general;m; //Dependencies for the target vtkhdf5_LIB_DEPENDS:STATIC=general;m;general;vtkzlib; //Dependencies for the target vtkhdf5_hl_LIB_DEPENDS:STATIC=general;vtkhdf5; //Dependencies for target vtkjpeg_LIB_DEPENDS:STATIC= //Dependencies for target vtkjsoncpp_LIB_DEPENDS:STATIC= //Value Computed by CMake vtklibxml2_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/libxml2/vtklibxml2 //Dependencies for the target vtklibxml2_LIB_DEPENDS:STATIC=general;vtkzlib;general;dl;general;-lpthread;general;dl;general;m; //Value Computed by CMake vtklibxml2_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/libxml2/vtklibxml2 //Value Computed by CMake vtkmetaio_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/MetaIO/vtkmetaio //Dependencies for the target vtkmetaio_LIB_DEPENDS:STATIC=general;vtkzlib; //Value Computed by CMake vtkmetaio_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/MetaIO/vtkmetaio //Dependencies for target vtkoggtheora_LIB_DEPENDS:STATIC= //Dependencies for the target vtkpng_LIB_DEPENDS:STATIC=general;vtkzlib;general;-lm; //Dependencies for the target vtkproj4_LIB_DEPENDS:STATIC=general;m; //Dependencies for the target vtksqlite_LIB_DEPENDS:STATIC=general;-lpthread; //Value Computed by CMake vtksys_BINARY_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/KWSys/vtksys //Dependencies for the target vtksys_LIB_DEPENDS:STATIC=general;dl;general;dl; //Value Computed by CMake vtksys_SOURCE_DIR:STATIC=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/Utilities/KWSys/vtksys //Dependencies for the target vtktiff_LIB_DEPENDS:STATIC=general;vtkzlib;general;vtkjpeg;general;-lm; //Dependencies for target vtkzlib_LIB_DEPENDS:STATIC= ######################## # INTERNAL cache entries ######################## ALGLIB_SHARED_LIB:INTERNAL=ON //Result of TRY_COMPILE CMAKE_ANSI_FOR_SCOPE:INTERNAL=TRUE //Have include iostream CMAKE_ANSI_STREAM_HEADERS:INTERNAL=1 //ADVANCED property for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //STRINGS property for variable: CMAKE_BUILD_TYPE CMAKE_BUILD_TYPE-STRINGS:INTERNAL=Debug;Release;MinSizeRel;RelWithDebInfo //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0 //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=0 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=2 //ADVANCED property for variable: CMAKE_COLOR_MAKEFILE CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/home/deepaksurti/Enthought/Canopy_64bit/User/bin/cmake //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=/home/deepaksurti/Enthought/Canopy_64bit/User/bin/cpack //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/home/deepaksurti/Enthought/Canopy_64bit/User/bin/ctest //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_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 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/home/deepaksurti/Enthought/Canopy_64bit/User/bin/ccmake //Executable file format CMAKE_EXECUTABLE_FORMAT:INTERNAL=ELF //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 generator. CMAKE_GENERATOR:INTERNAL=Unix Makefiles //Name of generator toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Result of TRY_COMPILE CMAKE_HAS_ANSI_STRING_STREAM:INTERNAL=TRUE //Have function connect CMAKE_HAVE_CONNECT:INTERNAL=1 //Have function gethostbyname CMAKE_HAVE_GETHOSTBYNAME:INTERNAL=1 //Have symbol pthread_create CMAKE_HAVE_LIBC_CREATE:INTERNAL= //Have library pthreads CMAKE_HAVE_PTHREADS_CREATE:INTERNAL= //Have library pthread CMAKE_HAVE_PTHREAD_CREATE:INTERNAL=1 //Have include pthread.h CMAKE_HAVE_PTHREAD_H:INTERNAL=1 //Have function remove CMAKE_HAVE_REMOVE:INTERNAL=1 //Have function shmat CMAKE_HAVE_SHMAT:INTERNAL=1 //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0 //Install .so files without execute permission. CMAKE_INSTALL_SO_NO_EXE:INTERNAL=0 //Have library ICE CMAKE_LIB_ICE_HAS_ICECONNECTIONNUMBER: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 //ADVANCED property for variable: CMAKE_NM CMAKE_NM-ADVANCED:INTERNAL=1 //Does the compiler support ansi for scope. CMAKE_NO_ANSI_FOR_SCOPE:INTERNAL=0 //ADVANCED property for variable: CMAKE_NO_ANSI_STREAM_HEADERS CMAKE_NO_ANSI_STREAM_HEADERS-ADVANCED:INTERNAL=1 //Does the compiler support headers like iostream. CMAKE_NO_ANSI_STREAM_HEADERS:INTERNAL=0 //Does the compiler support sstream CMAKE_NO_ANSI_STRING_STREAM:INTERNAL=0 //Does the compiler support std::. CMAKE_NO_STD_NAMESPACE:INTERNAL=0 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=141 //ADVANCED property for variable: CMAKE_OBJCOPY CMAKE_OBJCOPY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_OBJDUMP CMAKE_OBJDUMP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Test Support for 64 bit file systems CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/home/deepaksurti/Enthought/Canopy_64bit/User/share/cmake-3.0 //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 //Result of TRY_COMPILE CMAKE_STD_NAMESPACE:INTERNAL=TRUE //ADVANCED property for variable: CMAKE_STRIP CMAKE_STRIP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_THREAD_LIBS CMAKE_THREAD_LIBS-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/bin/uname //ADVANCED property for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Result of TEST_BIG_ENDIAN CMAKE_WORDS_BIGENDIAN:INTERNAL=0 //Compiler support for a deprecated attribute COMPILER_HAS_DEPRECATED:INTERNAL= //Result of TRY_COMPILE CXX_HAVE_OFFSETOF:INTERNAL=TRUE //Result of TRY_COMPILE DEV_T_IS_SCALAR:INTERNAL=FALSE //ADVANCED property for variable: EXODUSII_DISABLE_COMPILER_WARNINGS EXODUSII_DISABLE_COMPILER_WARNINGS-ADVANCED:INTERNAL=1 //Have include malloc.h EX_HAVE_MALLOC_H:INTERNAL=1 //ADVANCED property for variable: ExternalData_URL_TEMPLATES ExternalData_URL_TEMPLATES-ADVANCED:INTERNAL=1 //Details about finding OpenGL FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[/usr/lib64/libGL.so][/usr/include][v()] //Details about finding PythonLibs FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/lib/python2.7/config/libpython2.7.so][/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/include/python2.7][v()] //Details about finding Threads FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()] //Details about finding X11 FIND_PACKAGE_MESSAGE_DETAILS_X11:INTERNAL=[/usr/lib64/libX11.so][/usr/include] //Result of TRY_COMPILE GETTIMEOFDAY_GIVES_TZ:INTERNAL=FALSE //Test GLX_DECLARES_FUNCTION_glXGetProcAddress GLX_DECLARES_FUNCTION_glXGetProcAddress:INTERNAL= //Test GLX_DECLARES_FUNCTION_glXGetProcAddressARB GLX_DECLARES_FUNCTION_glXGetProcAddressARB:INTERNAL= //Test GLX_DECLARES_FUNCTION_glXGetProcAddressARB_AS_EMPTY GLX_DECLARES_FUNCTION_glXGetProcAddressARB_AS_EMPTY:INTERNAL= //Test GLX_DECLARES_FUNCTION_glXGetProcAddress_AS_EMPTY GLX_DECLARES_FUNCTION_glXGetProcAddress_AS_EMPTY:INTERNAL= //Test GLX_DEFINES_MACRO_GLX_ARB_get_proc_address GLX_DEFINES_MACRO_GLX_ARB_get_proc_address:INTERNAL= //Test GLX_DEFINES_MACRO_GLX_VERSION_1_1 GLX_DEFINES_MACRO_GLX_VERSION_1_1:INTERNAL= //Test GLX_DEFINES_MACRO_GLX_VERSION_1_2 GLX_DEFINES_MACRO_GLX_VERSION_1_2:INTERNAL= //Test GLX_DEFINES_MACRO_GLX_VERSION_1_3 GLX_DEFINES_MACRO_GLX_VERSION_1_3:INTERNAL= //Test GLX_DEFINES_MACRO_GLX_VERSION_1_4 GLX_DEFINES_MACRO_GLX_VERSION_1_4:INTERNAL= //Test GLX_DEFINES_TYPE_GLXFBConfig GLX_DEFINES_TYPE_GLXFBConfig:INTERNAL= //Test GLX_DEFINES_TYPE_GLXextFuncPtr GLX_DEFINES_TYPE_GLXextFuncPtr:INTERNAL= //Test GLX_DEFINES_TYPE_GLXextFuncPtr_AS_EMPTY GLX_DEFINES_TYPE_GLXextFuncPtr_AS_EMPTY:INTERNAL= //Test GLX_INCLUDES_GLXEXT GLX_INCLUDES_GLXEXT:INTERNAL= GLX_USES_MACRO_GLX_GLXEXT_LEGACY:INTERNAL=TRUE //Other test H5_CXX_HAVE_OFFSETOF:INTERNAL=1 //Other test H5_DEV_T_IS_SCALAR:INTERNAL= //Checking IF overflows normally converting floating-point to integer // values H5_FP_TO_INTEGER_OVERFLOW_WORKS:INTERNAL=1 //Result of TRY_COMPILE H5_FP_TO_INTEGER_OVERFLOW_WORKS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_INTEGER_OVERFLOW_WORKS_RUN:INTERNAL=0 //Checking IF accurately roundup converting floating-point to unsigned // long long values H5_FP_TO_ULLONG_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_FP_TO_ULLONG_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_ULLONG_ACCURATE_RUN:INTERNAL=0 //Checking IF right maximum converting floating-point to unsigned // long long values H5_FP_TO_ULLONG_RIGHT_MAXIMUM:INTERNAL=1 //Result of TRY_COMPILE H5_FP_TO_ULLONG_RIGHT_MAXIMUM_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_ULLONG_RIGHT_MAXIMUM_RUN:INTERNAL=0 //Other test H5_GETTIMEOFDAY_GIVES_TZ:INTERNAL= //Have function alarm H5_HAVE_ALARM:INTERNAL=1 //Other test H5_HAVE_ATTRIBUTE:INTERNAL=1 //Other test H5_HAVE_C99_DESIGNATED_INITIALIZER:INTERNAL=1 //Other test H5_HAVE_C99_FUNC:INTERNAL=1 //Have symbol tzname H5_HAVE_DECL_TZNAME:INTERNAL=1 //Have function difftime H5_HAVE_DIFFTIME:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h;dlfcn.h H5_HAVE_DLFCN_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h;dlfcn.h;features.h H5_HAVE_FEATURES_H:INTERNAL=1 //Have function fork H5_HAVE_FORK:INTERNAL=1 //Have function frexpf H5_HAVE_FREXPF:INTERNAL=1 //Have function frexpl H5_HAVE_FREXPL:INTERNAL=1 //Have function fseeko H5_HAVE_FSEEKO:INTERNAL=1 //Have function fstat64 H5_HAVE_FSTAT64:INTERNAL=1 //Have function ftello H5_HAVE_FTELLO:INTERNAL=1 //Other test H5_HAVE_FUNCTION:INTERNAL=1 //Have function gethostname H5_HAVE_GETHOSTNAME:INTERNAL=1 //Have function getpwuid H5_HAVE_GETPWUID:INTERNAL=1 //Have function getrusage H5_HAVE_GETRUSAGE:INTERNAL=1 //Have includes ;globus/common.h H5_HAVE_GLOBUS_COMMON_H:INTERNAL= //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h;dlfcn.h;features.h;inttypes.h H5_HAVE_INTTYPES_H:INTERNAL=1 //Have function ioctl H5_HAVE_IOCTL:INTERNAL=1 //Have includes ;io.h H5_HAVE_IO_H:INTERNAL= //Have library m; H5_HAVE_LIBM:INTERNAL=1 //Have library socket;m H5_HAVE_LIBSOCKET:INTERNAL= //Have library ucb;m H5_HAVE_LIBUCB:INTERNAL= //Have library ws2_32;m H5_HAVE_LIBWS2_32:INTERNAL= //Have library wsock32;m H5_HAVE_LIBWSOCK32:INTERNAL= //Have function longjmp H5_HAVE_LONGJMP:INTERNAL=1 //Have function lstat H5_HAVE_LSTAT:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h H5_HAVE_MEMORY_H:INTERNAL=1 //Have includes ;mfhdf.h H5_HAVE_MFHDF_H:INTERNAL= //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h;dlfcn.h;features.h;inttypes.h;netinet/in.h H5_HAVE_NETINET_IN_H:INTERNAL=1 //Other test H5_HAVE_OFF64_T:INTERNAL= //Have includes ;pdb.h H5_HAVE_PDB_H:INTERNAL= //Have include ;pthread.h H5_HAVE_PTHREAD_H:INTERNAL=1 //Have function random H5_HAVE_RANDOM:INTERNAL=1 //Have function rand_r H5_HAVE_RAND_R:INTERNAL=1 //Have function setjmp H5_HAVE_SETJMP:INTERNAL=1 //Have include pthread.h;setjmp.h H5_HAVE_SETJMP_H:INTERNAL=1 //Have function setsysinfo H5_HAVE_SETSYSINFO:INTERNAL= //Have function sigaction H5_HAVE_SIGACTION:INTERNAL=1 //Have function siglongjmp H5_HAVE_SIGLONGJMP:INTERNAL=1 //Have function signal H5_HAVE_SIGNAL:INTERNAL=1 //Have function sigprocmask H5_HAVE_SIGPROCMASK:INTERNAL=1 //Have function sigsetjmp H5_HAVE_SIGSETJMP:INTERNAL= //Have function snprintf H5_HAVE_SNPRINTF:INTERNAL=1 //Other test H5_HAVE_SOCKLEN_T:INTERNAL= //Have function srandom H5_HAVE_SRANDOM:INTERNAL=1 //Have includes pthread.h;setjmp.h;srbclient.h H5_HAVE_SRBCLIENT_H:INTERNAL= //Have function stat64 H5_HAVE_STAT64:INTERNAL=1 //Other test H5_HAVE_STAT_ST_BLOCKS:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h H5_HAVE_STDDEF_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h H5_HAVE_STDINT_H:INTERNAL=1 //Have include stdint.h H5_HAVE_STDINT_H_CXX:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h H5_HAVE_STDLIB_H:INTERNAL=1 //Have function strdup H5_HAVE_STRDUP:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h H5_HAVE_STRINGS_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h H5_HAVE_STRING_H:INTERNAL=1 //Other test H5_HAVE_STRUCT_TIMEZONE:INTERNAL= //Other test H5_HAVE_STRUCT_TM_TM_ZONE:INTERNAL=1 //Have function symlink H5_HAVE_SYMLINK:INTERNAL=1 //Have function system H5_HAVE_SYSTEM:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h H5_HAVE_SYS_IOCTL_H:INTERNAL=1 //Have includes pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/proc.h H5_HAVE_SYS_PROC_H:INTERNAL= //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h H5_HAVE_SYS_RESOURCE_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h H5_HAVE_SYS_SOCKET_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h H5_HAVE_SYS_STAT_H:INTERNAL=1 H5_HAVE_SYS_SYSINFO_H:INTERNAL= //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h H5_HAVE_SYS_TIMEB_H:INTERNAL=1 //H5_HAVE_SYS_TIME_GETTIMEOFDAY H5_HAVE_SYS_TIME_GETTIMEOFDAY:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h H5_HAVE_SYS_TIME_H:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h H5_HAVE_SYS_TYPES_H:INTERNAL=1 //Other test H5_HAVE_TIMEZONE:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h H5_HAVE_TIME_H:INTERNAL=1 //Have symbol TIOCGETD H5_HAVE_TIOCGETD:INTERNAL=1 //Have symbol TIOCGWINSZ H5_HAVE_TIOCGWINSZ:INTERNAL=1 //Other test H5_HAVE_TM_GMTOFF:INTERNAL=1 //Other test H5_HAVE_TM_ZONE:INTERNAL=1 //Have include pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h H5_HAVE_UNISTD_H:INTERNAL=1 //Have function vasprintf H5_HAVE_VASPRINTF:INTERNAL=1 //Have function vsnprintf H5_HAVE_VSNPRINTF:INTERNAL=1 //Have function waitpid H5_HAVE_WAITPID:INTERNAL=1 //Have includes pthread.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h;sys/ioctl.h;sys/resource.h;sys/socket.h;sys/stat.h;sys/time.h;time.h;sys/timeb.h;sys/types.h;unistd.h;stdlib.h;memory.h;dlfcn.h;features.h;inttypes.h;winsock.h H5_HAVE_WINSOCK_H:INTERNAL= //Other test H5_INLINE_TEST___inline:INTERNAL=1 //Other test H5_INLINE_TEST___inline__:INTERNAL=1 //Other test H5_INLINE_TEST_inline:INTERNAL=1 //checking IF accurately converting from integers to long double H5_INTEGER_TO_LDOUBLE_ACCURATE:INTERNAL=1 //checking IF converting from long double to integers is accurate H5_LDOUBLE_TO_INTEGER_ACCURATE:INTERNAL=1 //Checking IF converting from long double to integers works H5_LDOUBLE_TO_INTEGER_WORKS:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_INTEGER_WORKS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_INTEGER_WORKS_RUN:INTERNAL=0 //Checking IF correctly converting long double to (unsigned) long // long values H5_LDOUBLE_TO_LLONG_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_LLONG_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_LLONG_ACCURATE_RUN:INTERNAL=0 //Checking IF correctly converting long double to unsigned int // values H5_LDOUBLE_TO_UINT_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_UINT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_UINT_ACCURATE_RUN:INTERNAL=0 //Use Legacy Names for Libraries and Programs H5_LEGACY_NAMING:INTERNAL=ON //Checking IF compiling long long to floating-point typecasts work H5_LLONG_TO_FP_CAST_WORKS:INTERNAL=1 //Checking IF correctly converting (unsigned) long long to long // double values H5_LLONG_TO_LDOUBLE_CORRECT:INTERNAL=1 //Result of TRY_COMPILE H5_LLONG_TO_LDOUBLE_CORRECT_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LLONG_TO_LDOUBLE_CORRECT_RUN:INTERNAL=0 //Checking IF alignment restrictions are strictly enforced H5_NO_ALIGNMENT_RESTRICTIONS:INTERNAL=1 //Result of TRY_COMPILE H5_NO_ALIGNMENT_RESTRICTIONS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_NO_ALIGNMENT_RESTRICTIONS_RUN:INTERNAL=0 //Width for printf for type `long long' or `__int64', us. `ll H5_PRINTF_LL_WIDTH:INTERNAL="ll" //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=8 //CHECK_TYPE_SIZE: sizeof(int_fast32_t) H5_SIZEOF_INT_FAST32_T:INTERNAL=8 //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=8 //CHECK_TYPE_SIZE: sizeof(long double) H5_SIZEOF_LONG_DOUBLE:INTERNAL=16 //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=8 //CHECK_TYPE_SIZE: sizeof(short) H5_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(size_t) H5_SIZEOF_SIZE_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(ssize_t) H5_SIZEOF_SSIZE_T:INTERNAL=8 //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=8 //CHECK_TYPE_SIZE: sizeof(uint_fast32_t) H5_SIZEOF_UINT_FAST32_T:INTERNAL=8 //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 //SizeOf for __int64 H5_SIZEOF___INT64:INTERNAL=0 //Other test H5_STDC_HEADERS:INTERNAL=1 //Other test H5_SYSTEM_SCOPE_THREADS:INTERNAL=1 //Other test H5_TIME_WITH_SYS_TIME:INTERNAL=1 //Checking IF compiling unsigned long long to floating-point typecasts // work H5_ULLONG_TO_FP_CAST_WORKS:INTERNAL=1 //Checking IF converting unsigned long long to long double with // precision H5_ULLONG_TO_LDOUBLE_PRECISION:INTERNAL=1 //Result of TRY_COMPILE H5_ULLONG_TO_LDOUBLE_PRECISION_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULLONG_TO_LDOUBLE_PRECISION_RUN:INTERNAL=0 //Checking IF accurately converting unsigned long to float values H5_ULONG_TO_FLOAT_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_ULONG_TO_FLOAT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULONG_TO_FLOAT_ACCURATE_RUN:INTERNAL=0 //Checking IF accurately converting unsigned long long to floating-point // values H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE:INTERNAL= //Result of TRY_COMPILE H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE_RUN:INTERNAL=1 //Other test H5_VSNPRINTF_WORKS:INTERNAL=1 //Have symbol alloca HAVE_ALLOCA:INTERNAL=1 //Have include ;alloca.h HAVE_ALLOCA_H:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;ansidecl.h HAVE_ANSIDECL_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h HAVE_ARPA_INET_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h HAVE_ARPA_NAMESER_H:INTERNAL=1 //Have include assert.h HAVE_ASSERT_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_ATTRIBUTE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_C99_DESIGNATED_INITIALIZER:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_C99_FUNC:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_WORDS_BIGENDIAN:INTERNAL=TRUE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h HAVE_CTYPE_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h HAVE_DIRENT_H:INTERNAL=1 //Have include dlfcn.h HAVE_DLFCN_H:INTERNAL=1 //Have library dl;-lpthread;dl;m HAVE_DLOPEN:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;dl.h HAVE_DL_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.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 symbol finite HAVE_FINITE:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h HAVE_FLOAT_H:INTERNAL=1 //Have function floor HAVE_FLOOR:INTERNAL= //Have symbol fpclass HAVE_FPCLASS:INTERNAL= //Have symbol fprintf HAVE_FPRINTF:INTERNAL=1 //Have symbol fp_class HAVE_FP_CLASS:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;fp_class.h HAVE_FP_CLASS_H:INTERNAL= //Have symbol ftime HAVE_FTIME:INTERNAL=1 //NetCDF test HAVE_FTRUNCATE:INTERNAL=1 //Result of TRY_COMPILE HAVE_FUNCTION:INTERNAL=TRUE //Test HAVE_GCC_ERROR_RETURN_TYPE HAVE_GCC_ERROR_RETURN_TYPE:INTERNAL= //Test HAVE_GCC_VISIBILITY HAVE_GCC_VISIBILITY:INTERNAL=1 //Result of TRY_COMPILE HAVE_GETADDRINFO_COMPILED:INTERNAL=TRUE //Have function getopt HAVE_GETOPT:INTERNAL=1 //Have symbol gettimeofday HAVE_GETTIMEOFDAY:INTERNAL=1 //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=TRUE //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___INT64:INTERNAL=FALSE //Have includes ieeefp.h HAVE_IEEEFP_H:INTERNAL= //Test HAVE_INLINE_FUNCTIONS HAVE_INLINE_FUNCTIONS:INTERNAL=1 //Have include inttypes.h HAVE_INTTYPES_H:INTERNAL=1 //Have function isascii HAVE_ISASCII:INTERNAL=1 //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF___INT64:INTERNAL=FALSE //Have library dl; HAVE_LIBDL:INTERNAL=1 //Have include limits.h HAVE_LIMITS_H:INTERNAL=1 //Have symbol localtime HAVE_LOCALTIME:INTERNAL=1 //Have include malloc.h HAVE_MALLOC_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h HAVE_MATH_H:INTERNAL=1 //Have function memmove HAVE_MEMMOVE:INTERNAL=1 //Have include memory.h HAVE_MEMORY_H:INTERNAL=1 //Have function memset HAVE_MEMSET:INTERNAL=1 //Have function mmap HAVE_MMAP:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;nan.h HAVE_NAN_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;ndir.h HAVE_NDIR_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h HAVE_NETDB_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h HAVE_NETINET_IN_H:INTERNAL=1 //Test HAVE_NO_COMMON HAVE_NO_COMMON:INTERNAL=1 //Result of TRY_COMPILE HAVE_OFF64_T:INTERNAL=FALSE //Test HAVE_OMIT_FRAME_POINTER HAVE_OMIT_FRAME_POINTER:INTERNAL=1 //Have function pow HAVE_POW:INTERNAL= //Have symbol printf HAVE_PRINTF:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h HAVE_PTHREAD_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h HAVE_RESOLV_H:INTERNAL=1 //Have library dld;dl HAVE_SHLLOAD:INTERNAL= //Have symbol signal HAVE_SIGNAL:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.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_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_SIZE_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_SSIZE_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_UCHAR:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_SIZEOF__BOOL:INTERNAL=TRUE //Have symbol snprintf HAVE_SNPRINTF:INTERNAL=1 //Result of TRY_COMPILE HAVE_SOCKLEN_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_SOCKLEN_T_COMPILED:INTERNAL=TRUE //Have symbol sprintf HAVE_SPRINTF:INTERNAL=1 //Have function sqrt HAVE_SQRT:INTERNAL= //Have symbol sscanf HAVE_SSCANF:INTERNAL=1 //Have symbol stat HAVE_STAT:INTERNAL=1 //Result of TRY_COMPILE HAVE_STAT_ST_BLOCKS:INTERNAL=TRUE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h HAVE_STDARG_H:INTERNAL=1 //Have include alloca.h;stdlib.h;sys/types.h;sys/stat.h;unistd.h;fcntl.h;stdio.h;string.h;stddef.h;stdint.h;inttypes.h;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 alloca.h;stdlib.h;sys/types.h;sys/stat.h;unistd.h;fcntl.h;stdio.h HAVE_STDIO_H:INTERNAL=1 //Have include stdlib.h HAVE_STDLIB_H:INTERNAL=1 //Test HAVE_STD_C99 HAVE_STD_C99:INTERNAL=1 //Have function strcasecmp HAVE_STRCASECMP:INTERNAL=1 //Have function strchr HAVE_STRCHR:INTERNAL=1 //Have symbol strdup HAVE_STRDUP:INTERNAL=1 //Have symbol strerror HAVE_STRERROR:INTERNAL=1 //Have symbol strftime HAVE_STRFTIME:INTERNAL=1 //Have include strings.h HAVE_STRINGS_H:INTERNAL=1 //Have include string.h HAVE_STRING_H:INTERNAL=1 //Have symbol strndup HAVE_STRNDUP:INTERNAL=1 //Have function strrchr HAVE_STRRCHR:INTERNAL=1 //Have function strstr HAVE_STRSTR:INTERNAL=1 //Have function strtol HAVE_STRTOL:INTERNAL=1 //Have function strtoul HAVE_STRTOUL:INTERNAL=1 //Result of TRY_COMPILE HAVE_STRUCT_TIMEZONE:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_STRUCT_TM_TM_ZONE:INTERNAL=TRUE //NetCDF test HAVE_ST_BLKSIZE:INTERNAL=1 //Result of TRY_COMPILE HAVE_SYS_DIR_H_COMPILED:INTERNAL=TRUE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h;sys/mman.h HAVE_SYS_MMAN_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_SYS_NDIR_H_COMPILED:INTERNAL=FALSE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h HAVE_SYS_SELECT_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h HAVE_SYS_SOCKET_H:INTERNAL=1 //Have include sys/stat.h HAVE_SYS_STAT_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h;sys/mman.h;sys/timeb.h HAVE_SYS_TIMEB_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_SYS_TIME_GETTIMEOFDAY:INTERNAL=TRUE //Have include sys/time.h HAVE_SYS_TIME_H:INTERNAL=1 //Have include sys/types.h HAVE_SYS_TYPES_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_TIMEZONE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_TIME_GETTIMEOFDAY:INTERNAL=FALSE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h HAVE_TIME_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_TM_GMTOFF:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_TM_ZONE:INTERNAL=TRUE //Have include unistd.h HAVE_UNISTD_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_VA_COPY_COMPILED:INTERNAL=TRUE //Have symbol vfprintf HAVE_VFPRINTF:INTERNAL=1 //Have symbol vsnprintf HAVE_VSNPRINTF:INTERNAL=1 //Have symbol vsprintf HAVE_VSPRINTF:INTERNAL=1 //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_UINT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_UINT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_U_INT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_U_INT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_FLOAT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF___INT64:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_VTK_UINTPTR_T:INTERNAL=TRUE //Have includes windows.h HAVE_WINDOWS_H:INTERNAL= //Have symbol _stat HAVE__STAT:INTERNAL= //Result of TRY_COMPILE HAVE___VA_COPY_COMPILED:INTERNAL=TRUE //Allow External Library Building HDF5_ALLOW_EXTERNAL_SUPPORT:INTERNAL=OFF //Build HDF5 C++ Library HDF5_BUILD_CPP_LIB:INTERNAL=OFF //Build HIGH Level HDF5 Library HDF5_BUILD_HL_LIB:INTERNAL=ON //Disable compiler warnings HDF5_DISABLE_COMPILER_WARNINGS:INTERNAL=ON //Enable the function stack tracing (for developer debugging). HDF5_ENABLE_CODESTACK:INTERNAL=OFF //Enable code coverage for Libraries and Programs HDF5_ENABLE_COVERAGE:INTERNAL=OFF //Enable deprecated public API symbols HDF5_ENABLE_DEPRECATED_SYMBOLS:INTERNAL=ON //Enable GPFS hints for the MPI/POSIX file driver HDF5_ENABLE_GPFS:INTERNAL=OFF //Enable datasets larger than memory HDF5_ENABLE_HSIZET:INTERNAL=ON //Enable support for large (64-bit) files on Linux. HDF5_ENABLE_LARGE_FILE:INTERNAL=ON //Enable parallel build (requires MPI) HDF5_ENABLE_PARALLEL:INTERNAL=OFF //Use SZip Filter HDF5_ENABLE_SZIP_SUPPORT:INTERNAL=OFF //Enable Threadsafety HDF5_ENABLE_THREADSAFE:INTERNAL=OFF //Enable API tracing capability HDF5_ENABLE_TRACE:INTERNAL=OFF //Indicate that a memory checker is used HDF5_ENABLE_USING_MEMCHECKER:INTERNAL=OFF //Enable Zlib Filters HDF5_ENABLE_Z_LIB_SUPPORT:INTERNAL=ON //Securely clear file buffers before writing to file HDF5_Enable_Clear_File_Buffers:INTERNAL=ON //Instrument The library HDF5_Enable_Instrument:INTERNAL=OFF //Used to pass variables between directories HDF5_LIBRARIES_TO_EXPORT:INTERNAL=vtkhdf5;vtkhdf5_hl //Enable metadata trace file collection HDF5_METADATA_TRACE_FILE:INTERNAL=OFF //CPACK - include external libraries HDF5_PACKAGE_EXTLIBS:INTERNAL=OFF //Result of TRY_COMPILE HDF5_PRINTF_LL_TEST_COMPILE:INTERNAL=TRUE //Result of TRY_RUN HDF5_PRINTF_LL_TEST_RUN:INTERNAL=0 //Whether to perform strict file format checks HDF5_STRICT_FORMAT_CHECKS:INTERNAL=OFF //Use the HDF5 1.6.x API by default HDF5_USE_16_API_DEFAULT:INTERNAL=OFF //Use the FLETCHER32 Filter HDF5_USE_FILTER_FLETCHER32:INTERNAL=ON //Use the NBIT Filter HDF5_USE_FILTER_NBIT:INTERNAL=ON //Use the SCALEOFFSET Filter HDF5_USE_FILTER_SCALEOFFSET:INTERNAL=ON //Use the SHUFFLE Filter HDF5_USE_FILTER_SHUFFLE:INTERNAL=ON //Use the PACKED BITS feature in h5dump HDF5_USE_H5DUMP_PACKED_BITS:INTERNAL=ON //IF data accuracy is guaranteed during data conversions HDF5_WANT_DATA_ACCURACY:INTERNAL=ON //exception handling functions is checked during data conversions HDF5_WANT_DCONV_EXCEPTION:INTERNAL=ON //Result of TRY_COMPILE INLINE_TEST___inline:INTERNAL=TRUE //Result of TRY_COMPILE INLINE_TEST___inline__:INTERNAL=TRUE //Result of TRY_COMPILE INLINE_TEST_inline:INTERNAL=TRUE //Result of TRY_RUN KWSYS_CHAR_IS_SIGNED:INTERNAL=0 //Result of TRY_COMPILE KWSYS_CHAR_IS_SIGNED_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ARGUMENT_DEPENDENT_LOOKUP_COMPILED:INTERNAL=TRUE //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_BACKTRACE_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDDEF_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDIO_COMPILED:INTERNAL=TRUE //Have include cxxabi.h KWSYS_CXX_HAS_CXXABIH:INTERNAL=1 //Result of TRY_COMPILE KWSYS_CXX_HAS_CXXABI_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_DLADDR_COMPILED:INTERNAL=TRUE //Have include dlfcn.h KWSYS_CXX_HAS_DLFCNH:INTERNAL=1 //Result of TRY_COMPILE KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H_COMPILED:INTERNAL=FALSE //Have include execinfo.h KWSYS_CXX_HAS_EXECINFOH:INTERNAL=1 //Result of TRY_COMPILE KWSYS_CXX_HAS_FULL_SPECIALIZATION_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_LONG_LONG_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_MEMBER_TEMPLATES_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_NULL_TEMPLATE_ARGS_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_RLIMIT64_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_SETENV_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_UNSETENV_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMENSAT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMES_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS__ATOI64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS___INT64_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=TRUE //Result of TRY_COMPILE KWSYS_C_TYPE_MACROS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_BINARY_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_ANSI_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_SSTREAM_COMPILED:INTERNAL=TRUE //Result of TRY_RUN KWSYS_LFS_WORKS:INTERNAL=0 //Result of TRY_COMPILE KWSYS_LFS_WORKS_COMPILED:INTERNAL=TRUE //CHECK_TYPE_SIZE: sizeof(char) KWSYS_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(short) KWSYS_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: __int64 unknown KWSYS_SIZEOF___INT64:INTERNAL= //Result of TRY_COMPILE KWSYS_STAT_HAS_ST_MTIM_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_MAX_SIZE_ARGUMENT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_OBJECTS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_REBIND_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_TEMPLATE_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ITERATOR_TRAITS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_WSTRING_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_STRING_HAVE_NEQ_CHAR_COMPILED:INTERNAL=TRUE //Have include sys/types.h;ifaddrs.h KWSYS_SYS_HAS_IFADDRS_H:INTERNAL=1 //ADVANCED property for variable: Module_AutobahnPython Module_AutobahnPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_Twisted Module_Twisted-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_ZopeInterface Module_ZopeInterface-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsDax Module_vtkAcceleratorsDax-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsPiston Module_vtkAcceleratorsPiston-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkChartsCore Module_vtkChartsCore-ADVANCED:INTERNAL=1 //Request building vtkChartsCore Module_vtkChartsCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonColor Module_vtkCommonColor-ADVANCED:INTERNAL=1 //Request building vtkCommonColor Module_vtkCommonColor:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry-ADVANCED:INTERNAL=1 //Request building vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonCore Module_vtkCommonCore-ADVANCED:INTERNAL=1 //Request building vtkCommonCore Module_vtkCommonCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonDataModel Module_vtkCommonDataModel-ADVANCED:INTERNAL=1 //Request building vtkCommonDataModel Module_vtkCommonDataModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonExecutionModel Module_vtkCommonExecutionModel-ADVANCED:INTERNAL=1 //Request building vtkCommonExecutionModel Module_vtkCommonExecutionModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMath Module_vtkCommonMath-ADVANCED:INTERNAL=1 //Request building vtkCommonMath Module_vtkCommonMath:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMisc Module_vtkCommonMisc-ADVANCED:INTERNAL=1 //Request building vtkCommonMisc Module_vtkCommonMisc:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonSystem Module_vtkCommonSystem-ADVANCED:INTERNAL=1 //Request building vtkCommonSystem Module_vtkCommonSystem:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonTransforms Module_vtkCommonTransforms-ADVANCED:INTERNAL=1 //Request building vtkCommonTransforms Module_vtkCommonTransforms:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDICOMParser Module_vtkDICOMParser-ADVANCED:INTERNAL=1 //Request building vtkDICOMParser Module_vtkDICOMParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDomainsChemistry Module_vtkDomainsChemistry-ADVANCED:INTERNAL=1 //Request building vtkDomainsChemistry Module_vtkDomainsChemistry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersAMR Module_vtkFiltersAMR-ADVANCED:INTERNAL=1 //Request building vtkFiltersAMR Module_vtkFiltersAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersCore Module_vtkFiltersCore-ADVANCED:INTERNAL=1 //Request building vtkFiltersCore Module_vtkFiltersCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersExtraction Module_vtkFiltersExtraction-ADVANCED:INTERNAL=1 //Request building vtkFiltersExtraction Module_vtkFiltersExtraction:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersFlowPaths Module_vtkFiltersFlowPaths-ADVANCED:INTERNAL=1 //Request building vtkFiltersFlowPaths Module_vtkFiltersFlowPaths:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeneral Module_vtkFiltersGeneral-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeneral Module_vtkFiltersGeneral:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeneric Module_vtkFiltersGeneric-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeneric Module_vtkFiltersGeneric:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeometry Module_vtkFiltersGeometry-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeometry Module_vtkFiltersGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersHybrid Module_vtkFiltersHybrid-ADVANCED:INTERNAL=1 //Request building vtkFiltersHybrid Module_vtkFiltersHybrid:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersHyperTree Module_vtkFiltersHyperTree-ADVANCED:INTERNAL=1 //Request building vtkFiltersHyperTree Module_vtkFiltersHyperTree:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersImaging Module_vtkFiltersImaging-ADVANCED:INTERNAL=1 //Request building vtkFiltersImaging Module_vtkFiltersImaging:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersModeling Module_vtkFiltersModeling-ADVANCED:INTERNAL=1 //Request building vtkFiltersModeling Module_vtkFiltersModeling:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallel Module_vtkFiltersParallel-ADVANCED:INTERNAL=1 //Request building vtkFiltersParallel Module_vtkFiltersParallel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelImaging Module_vtkFiltersParallelImaging-ADVANCED:INTERNAL=1 //Request building vtkFiltersParallelImaging Module_vtkFiltersParallelImaging:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallelMPI Module_vtkFiltersParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersProgrammable Module_vtkFiltersProgrammable-ADVANCED:INTERNAL=1 //Request building vtkFiltersProgrammable Module_vtkFiltersProgrammable:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersReebGraph Module_vtkFiltersReebGraph-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersSMP Module_vtkFiltersSMP-ADVANCED:INTERNAL=1 //Request building vtkFiltersSMP Module_vtkFiltersSMP:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersSelection Module_vtkFiltersSelection-ADVANCED:INTERNAL=1 //Request building vtkFiltersSelection Module_vtkFiltersSelection:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersSources Module_vtkFiltersSources-ADVANCED:INTERNAL=1 //Request building vtkFiltersSources Module_vtkFiltersSources:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersStatistics Module_vtkFiltersStatistics-ADVANCED:INTERNAL=1 //Request building vtkFiltersStatistics Module_vtkFiltersStatistics:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersTexture Module_vtkFiltersTexture-ADVANCED:INTERNAL=1 //Request building vtkFiltersTexture Module_vtkFiltersTexture:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersVerdict Module_vtkFiltersVerdict-ADVANCED:INTERNAL=1 //Request building vtkFiltersVerdict Module_vtkFiltersVerdict:INTERNAL=OFF //ADVANCED property for variable: Module_vtkGUISupportQt Module_vtkGUISupportQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtSQL Module_vtkGUISupportQtSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGeovisCore Module_vtkGeovisCore-ADVANCED:INTERNAL=1 //Request building vtkGeovisCore Module_vtkGeovisCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOAMR Module_vtkIOAMR-ADVANCED:INTERNAL=1 //Request building vtkIOAMR Module_vtkIOAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOCore Module_vtkIOCore-ADVANCED:INTERNAL=1 //Request building vtkIOCore Module_vtkIOCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOEnSight Module_vtkIOEnSight-ADVANCED:INTERNAL=1 //Request building vtkIOEnSight Module_vtkIOEnSight:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOExodus Module_vtkIOExodus-ADVANCED:INTERNAL=1 //Request building vtkIOExodus Module_vtkIOExodus:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOExport Module_vtkIOExport-ADVANCED:INTERNAL=1 //Request building vtkIOExport Module_vtkIOExport:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOFFMPEG Module_vtkIOFFMPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGDAL Module_vtkIOGDAL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeoJSON Module_vtkIOGeoJSON-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeometry Module_vtkIOGeometry-ADVANCED:INTERNAL=1 //Request building vtkIOGeometry Module_vtkIOGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOImage Module_vtkIOImage-ADVANCED:INTERNAL=1 //Request building vtkIOImage Module_vtkIOImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOImport Module_vtkIOImport-ADVANCED:INTERNAL=1 //Request building vtkIOImport Module_vtkIOImport:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOInfovis Module_vtkIOInfovis-ADVANCED:INTERNAL=1 //Request building vtkIOInfovis Module_vtkIOInfovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOLSDyna Module_vtkIOLSDyna-ADVANCED:INTERNAL=1 //Request building vtkIOLSDyna Module_vtkIOLSDyna:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOLegacy Module_vtkIOLegacy-ADVANCED:INTERNAL=1 //Request building vtkIOLegacy Module_vtkIOLegacy:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMINC Module_vtkIOMINC-ADVANCED:INTERNAL=1 //Request building vtkIOMINC Module_vtkIOMINC:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMPIImage Module_vtkIOMPIImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMPIParallel Module_vtkIOMPIParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMovie Module_vtkIOMovie-ADVANCED:INTERNAL=1 //Request building vtkIOMovie Module_vtkIOMovie:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMySQL Module_vtkIOMySQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIONetCDF Module_vtkIONetCDF-ADVANCED:INTERNAL=1 //Request building vtkIONetCDF Module_vtkIONetCDF:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOODBC Module_vtkIOODBC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPLY Module_vtkIOPLY-ADVANCED:INTERNAL=1 //Request building vtkIOPLY Module_vtkIOPLY:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOParallel Module_vtkIOParallel-ADVANCED:INTERNAL=1 //Request building vtkIOParallel Module_vtkIOParallel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOParallelExodus Module_vtkIOParallelExodus-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelLSDyna Module_vtkIOParallelLSDyna-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelNetCDF Module_vtkIOParallelNetCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPostgreSQL Module_vtkIOPostgreSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOSQL Module_vtkIOSQL-ADVANCED:INTERNAL=1 //Request building vtkIOSQL Module_vtkIOSQL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOVPIC Module_vtkIOVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOVideo Module_vtkIOVideo-ADVANCED:INTERNAL=1 //Request building vtkIOVideo Module_vtkIOVideo:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXML Module_vtkIOXML-ADVANCED:INTERNAL=1 //Request building vtkIOXML Module_vtkIOXML:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXMLParser Module_vtkIOXMLParser-ADVANCED:INTERNAL=1 //Request building vtkIOXMLParser Module_vtkIOXMLParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXdmf2 Module_vtkIOXdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingColor Module_vtkImagingColor-ADVANCED:INTERNAL=1 //Request building vtkImagingColor Module_vtkImagingColor:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingCore Module_vtkImagingCore-ADVANCED:INTERNAL=1 //Request building vtkImagingCore Module_vtkImagingCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingFourier Module_vtkImagingFourier-ADVANCED:INTERNAL=1 //Request building vtkImagingFourier Module_vtkImagingFourier:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingGeneral Module_vtkImagingGeneral-ADVANCED:INTERNAL=1 //Request building vtkImagingGeneral Module_vtkImagingGeneral:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingHybrid Module_vtkImagingHybrid-ADVANCED:INTERNAL=1 //Request building vtkImagingHybrid Module_vtkImagingHybrid:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingMath Module_vtkImagingMath-ADVANCED:INTERNAL=1 //Request building vtkImagingMath Module_vtkImagingMath:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingMorphological Module_vtkImagingMorphological-ADVANCED:INTERNAL=1 //Request building vtkImagingMorphological Module_vtkImagingMorphological:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingSources Module_vtkImagingSources-ADVANCED:INTERNAL=1 //Request building vtkImagingSources Module_vtkImagingSources:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingStatistics Module_vtkImagingStatistics-ADVANCED:INTERNAL=1 //Request building vtkImagingStatistics Module_vtkImagingStatistics:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingStencil Module_vtkImagingStencil-ADVANCED:INTERNAL=1 //Request building vtkImagingStencil Module_vtkImagingStencil:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisBoost Module_vtkInfovisBoost-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisCore Module_vtkInfovisCore-ADVANCED:INTERNAL=1 //Request building vtkInfovisCore Module_vtkInfovisCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisLayout Module_vtkInfovisLayout-ADVANCED:INTERNAL=1 //Request building vtkInfovisLayout Module_vtkInfovisLayout:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisParallel Module_vtkInfovisParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInteractionImage Module_vtkInteractionImage-ADVANCED:INTERNAL=1 //Request building vtkInteractionImage Module_vtkInteractionImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInteractionStyle Module_vtkInteractionStyle-ADVANCED:INTERNAL=1 //Request building vtkInteractionStyle Module_vtkInteractionStyle:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInteractionWidgets Module_vtkInteractionWidgets-ADVANCED:INTERNAL=1 //Request building vtkInteractionWidgets Module_vtkInteractionWidgets:INTERNAL=OFF //ADVANCED property for variable: Module_vtkMetaIO Module_vtkMetaIO-ADVANCED:INTERNAL=1 //Request building vtkMetaIO Module_vtkMetaIO:INTERNAL=OFF //ADVANCED property for variable: Module_vtkParallelCore Module_vtkParallelCore-ADVANCED:INTERNAL=1 //Request building vtkParallelCore Module_vtkParallelCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkParallelMPI Module_vtkParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkParseOGLExt Module_vtkParseOGLExt-ADVANCED:INTERNAL=1 //Request building vtkParseOGLExt Module_vtkParseOGLExt:INTERNAL=OFF //ADVANCED property for variable: Module_vtkPython Module_vtkPython-ADVANCED:INTERNAL=1 //Request building vtkPython Module_vtkPython:INTERNAL=OFF //ADVANCED property for variable: Module_vtkPythonInterpreter Module_vtkPythonInterpreter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingAnnotation Module_vtkRenderingAnnotation-ADVANCED:INTERNAL=1 //Request building vtkRenderingAnnotation Module_vtkRenderingAnnotation:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingContext2D Module_vtkRenderingContext2D-ADVANCED:INTERNAL=1 //Request building vtkRenderingContext2D Module_vtkRenderingContext2D:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingCore Module_vtkRenderingCore-ADVANCED:INTERNAL=1 //Request building vtkRenderingCore Module_vtkRenderingCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingFreeType Module_vtkRenderingFreeType-ADVANCED:INTERNAL=1 //Request building vtkRenderingFreeType Module_vtkRenderingFreeType:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingFreeTypeOpenGL Module_vtkRenderingFreeTypeOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingFreeTypeOpenGL Module_vtkRenderingFreeTypeOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingGL2PS Module_vtkRenderingGL2PS-ADVANCED:INTERNAL=1 //Request building vtkRenderingGL2PS Module_vtkRenderingGL2PS:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingImage Module_vtkRenderingImage-ADVANCED:INTERNAL=1 //Request building vtkRenderingImage Module_vtkRenderingImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLIC Module_vtkRenderingLIC-ADVANCED:INTERNAL=1 //Request building vtkRenderingLIC Module_vtkRenderingLIC:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLOD Module_vtkRenderingLOD-ADVANCED:INTERNAL=1 //Request building vtkRenderingLOD Module_vtkRenderingLOD:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLabel Module_vtkRenderingLabel-ADVANCED:INTERNAL=1 //Request building vtkRenderingLabel Module_vtkRenderingLabel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingMatplotlib Module_vtkRenderingMatplotlib-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingOpenGL Module_vtkRenderingOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingOpenGL Module_vtkRenderingOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingParallel Module_vtkRenderingParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingParallelLIC Module_vtkRenderingParallelLIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingQt Module_vtkRenderingQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingTk Module_vtkRenderingTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolume Module_vtkRenderingVolume-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolume Module_vtkRenderingVolume:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkTclTk Module_vtkTclTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingCore Module_vtkTestingCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingGenericBridge Module_vtkTestingGenericBridge-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingIOSQL Module_vtkTestingIOSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingRendering Module_vtkTestingRendering-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString-ADVANCED:INTERNAL=1 //Request building vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString:INTERNAL=OFF //ADVANCED property for variable: Module_vtkUtilitiesHashSource Module_vtkUtilitiesHashSource-ADVANCED:INTERNAL=1 //Request building vtkUtilitiesHashSource Module_vtkUtilitiesHashSource:INTERNAL=OFF //ADVANCED property for variable: Module_vtkVPIC Module_vtkVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsContext2D Module_vtkViewsContext2D-ADVANCED:INTERNAL=1 //Request building vtkViewsContext2D Module_vtkViewsContext2D:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsCore Module_vtkViewsCore-ADVANCED:INTERNAL=1 //Request building vtkViewsCore Module_vtkViewsCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsGeovis Module_vtkViewsGeovis-ADVANCED:INTERNAL=1 //Request building vtkViewsGeovis Module_vtkViewsGeovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsInfovis Module_vtkViewsInfovis-ADVANCED:INTERNAL=1 //Request building vtkViewsInfovis Module_vtkViewsInfovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsQt Module_vtkViewsQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebApplications Module_vtkWebApplications-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebCore Module_vtkWebCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebGLExporter Module_vtkWebGLExporter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebInstall Module_vtkWebInstall-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebJavaScript Module_vtkWebJavaScript-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebPython Module_vtkWebPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingJava Module_vtkWrappingJava-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingPythonCore Module_vtkWrappingPythonCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTcl Module_vtkWrappingTcl-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTools Module_vtkWrappingTools-ADVANCED:INTERNAL=1 //Request building vtkWrappingTools Module_vtkWrappingTools:INTERNAL=OFF //ADVANCED property for variable: Module_vtkalglib Module_vtkalglib-ADVANCED:INTERNAL=1 //Request building vtkalglib Module_vtkalglib:INTERNAL=OFF //ADVANCED property for variable: Module_vtkexodusII Module_vtkexodusII-ADVANCED:INTERNAL=1 //Request building vtkexodusII Module_vtkexodusII:INTERNAL=OFF //ADVANCED property for variable: Module_vtkexpat Module_vtkexpat-ADVANCED:INTERNAL=1 //Request building vtkexpat Module_vtkexpat:INTERNAL=OFF //ADVANCED property for variable: Module_vtkfreetype Module_vtkfreetype-ADVANCED:INTERNAL=1 //Request building vtkfreetype Module_vtkfreetype:INTERNAL=OFF //ADVANCED property for variable: Module_vtkftgl Module_vtkftgl-ADVANCED:INTERNAL=1 //Request building vtkftgl Module_vtkftgl:INTERNAL=OFF //ADVANCED property for variable: Module_vtkgl2ps Module_vtkgl2ps-ADVANCED:INTERNAL=1 //Request building vtkgl2ps Module_vtkgl2ps:INTERNAL=OFF //ADVANCED property for variable: Module_vtkhdf5 Module_vtkhdf5-ADVANCED:INTERNAL=1 //Request building vtkhdf5 Module_vtkhdf5:INTERNAL=OFF //ADVANCED property for variable: Module_vtkjpeg Module_vtkjpeg-ADVANCED:INTERNAL=1 //Request building vtkjpeg Module_vtkjpeg:INTERNAL=OFF //ADVANCED property for variable: Module_vtkjsoncpp Module_vtkjsoncpp-ADVANCED:INTERNAL=1 //Request building vtkjsoncpp Module_vtkjsoncpp:INTERNAL=OFF //ADVANCED property for variable: Module_vtklibproj4 Module_vtklibproj4-ADVANCED:INTERNAL=1 //Request building vtklibproj4 Module_vtklibproj4:INTERNAL=OFF //ADVANCED property for variable: Module_vtklibxml2 Module_vtklibxml2-ADVANCED:INTERNAL=1 //Request building vtklibxml2 Module_vtklibxml2:INTERNAL=OFF //ADVANCED property for variable: Module_vtkmrmpi Module_vtkmrmpi-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtknetcdf Module_vtknetcdf-ADVANCED:INTERNAL=1 //Request building vtknetcdf Module_vtknetcdf:INTERNAL=OFF //ADVANCED property for variable: Module_vtkoggtheora Module_vtkoggtheora-ADVANCED:INTERNAL=1 //Request building vtkoggtheora Module_vtkoggtheora:INTERNAL=OFF //ADVANCED property for variable: Module_vtkpng Module_vtkpng-ADVANCED:INTERNAL=1 //Request building vtkpng Module_vtkpng:INTERNAL=OFF //ADVANCED property for variable: Module_vtksqlite Module_vtksqlite-ADVANCED:INTERNAL=1 //Request building vtksqlite Module_vtksqlite:INTERNAL=OFF //ADVANCED property for variable: Module_vtksys Module_vtksys-ADVANCED:INTERNAL=1 //Request building vtksys Module_vtksys:INTERNAL=OFF //ADVANCED property for variable: Module_vtktiff Module_vtktiff-ADVANCED:INTERNAL=1 //Request building vtktiff Module_vtktiff:INTERNAL=OFF //ADVANCED property for variable: Module_vtkverdict Module_vtkverdict-ADVANCED:INTERNAL=1 //Request building vtkverdict Module_vtkverdict:INTERNAL=OFF //ADVANCED property for variable: Module_vtkxdmf2 Module_vtkxdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkzlib Module_vtkzlib-ADVANCED:INTERNAL=1 //Request building vtkzlib Module_vtkzlib:INTERNAL=OFF //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_NELEMS NETCDF4_CHUNK_CACHE_NELEMS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_PREEMPTION NETCDF4_CHUNK_CACHE_PREEMPTION-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_SIZE NETCDF4_CHUNK_CACHE_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_DEFAULT_CHUNKS_IN_CACHE NETCDF4_DEFAULT_CHUNKS_IN_CACHE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_DEFAULT_CHUNK_SIZE NETCDF4_DEFAULT_CHUNK_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_MAX_DEFAULT_CACHE_SIZE NETCDF4_MAX_DEFAULT_CACHE_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF_DISABLE_COMPILER_WARNINGS NETCDF_DISABLE_COMPILER_WARNINGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF_ENABLE_CXX NETCDF_ENABLE_CXX-ADVANCED:INTERNAL=1 //Have library c NOT_NEED_LIBNSL:INTERNAL=1 //ADVANCED property for variable: NVCtrlLib_INCLUDE_DIR NVCtrlLib_INCLUDE_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NVCtrlLib_LIBRARY NVCtrlLib_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: OPENGL_INCLUDE_DIR OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1 //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: OPENGL_xmesa_INCLUDE_DIR OPENGL_xmesa_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Have symbol atanh PROJ_HAVE_ATANH:INTERNAL=1 //Have symbol csin PROJ_HAVE_COMPLEX:INTERNAL=1 //ADVANCED property for variable: PROJ_LIST_EXTERNAL PROJ_LIST_EXTERNAL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PROJ_USE_GSL PROJ_USE_GSL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PROJ_USE_PTHREADS PROJ_USE_PTHREADS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PYTHON_EXECUTABLE PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PYTHON_INCLUDE_DIR PYTHON_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Path to where Python.h is found (deprecated) PYTHON_INCLUDE_PATH:INTERNAL=/home/deepaksurti/Canopy/appdata/canopy-1.5.1.2730.rh5-x86_64/include/python2.7 //ADVANCED property for variable: PYTHON_LIBRARY PYTHON_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PYTHON_UTIL_LIBRARY PYTHON_UTIL_LIBRARY-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=8 //CHECK_TYPE_SIZE: sizeof(off_t) SIZEOF_OFF_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(ptrdiff_t) SIZEOF_PTRDIFF_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(short) SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(size_t) SIZEOF_SIZE_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(ssize_t) SIZEOF_SSIZE_T:INTERNAL=8 //CHECK_TYPE_SIZE: uchar unknown SIZEOF_UCHAR:INTERNAL= //CHECK_TYPE_SIZE: sizeof(_Bool) SIZEOF__BOOL:INTERNAL=1 //Result of TRY_COMPILE STDC_HEADERS:INTERNAL=TRUE //Result of TRY_COMPILE SUPPORT_IP6_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE SYSTEM_SCOPE_THREADS:INTERNAL=TRUE //Result of TRY_COMPILE TIME_WITH_SYS_TIME:INTERNAL=TRUE //ADVANCED property for variable: VERDICT_BUILD_DOC VERDICT_BUILD_DOC-ADVANCED:INTERNAL=1 //Build the 2007 Verdict User Manual VERDICT_BUILD_DOC:INTERNAL=OFF //ADVANCED property for variable: VERDICT_ENABLE_TESTING VERDICT_ENABLE_TESTING-ADVANCED:INTERNAL=1 //Should tests of the VERDICT library be built? VERDICT_ENABLE_TESTING:INTERNAL=OFF //ADVANCED property for variable: VERDICT_MANGLE VERDICT_MANGLE-ADVANCED:INTERNAL=1 //Mangle verdict names for inclusion in a larger library? VERDICT_MANGLE:INTERNAL=OFF //A string to prepend to all verdict function names and classes. VERDICT_MANGLE_PREFIX:INTERNAL= //Result of TRY_COMPILE VSNPRINTF_WORKS:INTERNAL=TRUE //ADVANCED property for variable: VTKOGGTHEORA_DISABLE_ASM VTKOGGTHEORA_DISABLE_ASM-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTKOGGTHEORA_DISABLE_FLOAT VTKOGGTHEORA_DISABLE_FLOAT-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int) VTKOGGTHEORA_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int16_t) VTKOGGTHEORA_INT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(int32_t) VTKOGGTHEORA_INT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int64_t) VTKOGGTHEORA_INT64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(long) VTKOGGTHEORA_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(long long) VTKOGGTHEORA_LONG_LONG:INTERNAL=8 //ADVANCED property for variable: VTKOGGTHEORA_SHARED_LINKER_FLAGS VTKOGGTHEORA_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(short) VTKOGGTHEORA_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint16_t) VTKOGGTHEORA_UINT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint32_t) VTKOGGTHEORA_UINT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(u_int16_t) VTKOGGTHEORA_U_INT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(u_int32_t) VTKOGGTHEORA_U_INT32_T:INTERNAL=4 //ADVANCED property for variable: VTK_ALL_NEW_OBJECT_FACTORY VTK_ALL_NEW_OBJECT_FACTORY-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE VTK_ANSI_STREAM_EOF_COMPILED:INTERNAL=TRUE //Result of TRY_RUN VTK_ANSI_STREAM_EOF_RESULT:INTERNAL=0 //ADVANCED property for variable: VTK_BUILD_ALL_MODULES VTK_BUILD_ALL_MODULES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_BUILD_PYTHON_MODULE_DIR VTK_BUILD_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Support for full template specialization syntax VTK_COMPILER_HAS_FULL_SPECIALIZATION:INTERNAL=1 //Test VTK_CONST_REVERSE_ITERATOR_COMPARISON VTK_CONST_REVERSE_ITERATOR_COMPARISON: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 //Support for C++ explict templates VTK_EXPLICIT_TEMPLATES:INTERNAL=1 //ADVANCED property for variable: VTK_GLEXT_FILE VTK_GLEXT_FILE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_GLXEXT_FILE VTK_GLXEXT_FILE-ADVANCED:INTERNAL=1 //Have symbol feenableexcept VTK_HAS_FEENABLEEXCEPT:INTERNAL=1 //Have symbol finite VTK_HAS_FINITE:INTERNAL=1 //Have symbol isfinite VTK_HAS_ISFINITE:INTERNAL= //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=1 //Have library socket VTK_HAVE_LIBSOCKET:INTERNAL= //Have symbol SO_REUSEADDR VTK_HAVE_SO_REUSEADDR:INTERNAL=1 //For __sync atomic builtins. VTK_HAVE_SYNC_BUILTINS:INTERNAL=1 //VTK modular always ignores BTX VTK_IGNORE_BTX:INTERNAL=ON //ADVANCED property for variable: VTK_IGNORE_GLDRIVER_BUGS VTK_IGNORE_GLDRIVER_BUGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_INSTALL_PYTHON_MODULE_DIR VTK_INSTALL_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Whether istream supports long long VTK_ISTREAM_SUPPORTS_LONG_LONG: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_MAKE_INSTANTIATORS VTK_MAKE_INSTANTIATORS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_MAX_THREADS VTK_MAX_THREADS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_OPENGL_HAS_OSMESA VTK_OPENGL_HAS_OSMESA-ADVANCED:INTERNAL=1 //Whether ostream supports long long VTK_OSTREAM_SUPPORTS_LONG_LONG:INTERNAL=1 //ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS VTK_REPORT_OPENGL_ERRORS-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(char) VTK_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(double) VTK_SIZEOF_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(float) VTK_SIZEOF_FLOAT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int) VTK_SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) VTK_SIZEOF_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(long long) VTK_SIZEOF_LONG_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(short) VTK_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: __int64 unknown VTK_SIZEOF___INT64:INTERNAL= //STRINGS property for variable: VTK_SMP_IMPLEMENTATION_TYPE VTK_SMP_IMPLEMENTATION_TYPE-STRINGS:INTERNAL=Sequential;Simple;Kaapi;TBB //Result of TRY_COMPILE VTK_TEST_SYNC_BUILTINS_COMPILED:INTERNAL=TRUE //Whether char is signed. VTK_TYPE_CHAR_IS_SIGNED:INTERNAL=1 //Result of TRY_COMPILE VTK_TYPE_CHAR_IS_SIGNED_COMPILED:INTERNAL=TRUE //CHECK_TYPE_SIZE: sizeof(uintptr_t) VTK_UINTPTR_T:INTERNAL=8 //ADVANCED property for variable: VTK_USE_64BIT_IDS VTK_USE_64BIT_IDS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_GCC_VISIBILITY VTK_USE_GCC_VISIBILITY-ADVANCED:INTERNAL=1 //Have function glXGetProcAddress VTK_USE_GLX_GET_PROC_ADDRESS:INTERNAL= //Have function glXGetProcAddressARB VTK_USE_GLX_GET_PROC_ADDRESS_ARB:INTERNAL= //ADVANCED property for variable: VTK_USE_OFFSCREEN VTK_USE_OFFSCREEN-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_EXPAT VTK_USE_SYSTEM_EXPAT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_FREETYPE VTK_USE_SYSTEM_FREETYPE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_GL2PS VTK_USE_SYSTEM_GL2PS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_HDF5 VTK_USE_SYSTEM_HDF5-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JPEG VTK_USE_SYSTEM_JPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JSONCPP VTK_USE_SYSTEM_JSONCPP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBPROJ4 VTK_USE_SYSTEM_LIBPROJ4-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBXML2 VTK_USE_SYSTEM_LIBXML2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_NETCDF VTK_USE_SYSTEM_NETCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_OGGTHEORA VTK_USE_SYSTEM_OGGTHEORA-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_PNG VTK_USE_SYSTEM_PNG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_TIFF VTK_USE_SYSTEM_TIFF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_ZLIB VTK_USE_SYSTEM_ZLIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_TDX VTK_USE_TDX-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_X VTK_USE_X-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_WGLEXT_FILE VTK_WGLEXT_FILE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_WRAP_HINTS VTK_WRAP_HINTS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_ICE_INCLUDE_PATH X11_ICE_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_ICE_LIB X11_ICE_LIB-ADVANCED:INTERNAL=1 //Have library dnet X11_LIB_DNET_HAS_DNET_NTOA:INTERNAL= //Have library dnet_stub X11_LIB_DNET_STUB_HAS_DNET_NTOA:INTERNAL= //Have library /usr/lib64/libX11.so;/usr/lib64/libXext.so X11_LIB_X11_SOLO:INTERNAL= //ADVANCED property for variable: X11_SM_INCLUDE_PATH X11_SM_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_SM_LIB X11_SM_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_X11_INCLUDE_PATH X11_X11_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_X11_LIB X11_X11_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XRes_INCLUDE_PATH X11_XRes_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XRes_LIB X11_XRes_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XShm_INCLUDE_PATH X11_XShm_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XSync_INCLUDE_PATH X11_XSync_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XTest_INCLUDE_PATH X11_XTest_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_XTest_LIB X11_XTest_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xaccessrules_INCLUDE_PATH X11_Xaccessrules_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xaccessstr_INCLUDE_PATH X11_Xaccessstr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xau_INCLUDE_PATH X11_Xau_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xau_LIB X11_Xau_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xcomposite_INCLUDE_PATH X11_Xcomposite_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xcomposite_LIB X11_Xcomposite_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xcursor_INCLUDE_PATH X11_Xcursor_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xcursor_LIB X11_Xcursor_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xdamage_INCLUDE_PATH X11_Xdamage_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xdamage_LIB X11_Xdamage_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xdmcp_INCLUDE_PATH X11_Xdmcp_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xdmcp_LIB X11_Xdmcp_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xext_LIB X11_Xext_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xfixes_INCLUDE_PATH X11_Xfixes_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xfixes_LIB X11_Xfixes_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xft_INCLUDE_PATH X11_Xft_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xft_LIB X11_Xft_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xi_INCLUDE_PATH X11_Xi_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xi_LIB X11_Xi_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xinerama_INCLUDE_PATH X11_Xinerama_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xinerama_LIB X11_Xinerama_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xinput_INCLUDE_PATH X11_Xinput_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xinput_LIB X11_Xinput_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xkb_INCLUDE_PATH X11_Xkb_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xkbfile_INCLUDE_PATH X11_Xkbfile_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xkbfile_LIB X11_Xkbfile_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xkblib_INCLUDE_PATH X11_Xkblib_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xlib_INCLUDE_PATH X11_Xlib_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xmu_INCLUDE_PATH X11_Xmu_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xmu_LIB X11_Xmu_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xpm_INCLUDE_PATH X11_Xpm_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xpm_LIB X11_Xpm_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xrender_INCLUDE_PATH X11_Xrender_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xrender_LIB X11_Xrender_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xscreensaver_INCLUDE_PATH X11_Xscreensaver_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xscreensaver_LIB X11_Xscreensaver_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xshape_INCLUDE_PATH X11_Xshape_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xt_INCLUDE_PATH X11_Xt_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xt_LIB X11_Xt_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xutil_INCLUDE_PATH X11_Xutil_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xv_INCLUDE_PATH X11_Xv_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xv_LIB X11_Xv_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xxf86misc_LIB X11_Xxf86misc_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_Xxf86vm_LIB X11_Xxf86vm_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_dpms_INCLUDE_PATH X11_dpms_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_xf86misc_INCLUDE_PATH X11_xf86misc_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: X11_xf86vmode_INCLUDE_PATH X11_xf86vmode_INCLUDE_PATH-ADVANCED:INTERNAL=1 netcdf_cxx_SOURCES:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx/netcdf.cpp;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx/ncvalues.cpp netcdf_dispatch_SOURCES:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/parallel.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/copy.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/file.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/dim.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/att.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/error.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/var.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/dispatch.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nc_url.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nclist.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/ncbytes.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/ncbytes.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nc4.c netcdf_liblib_SOURCES:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/liblib/stub.c netcdf_src4_SOURCES:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4internal.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/error4.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dispatch.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dispatch.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4attr.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dim.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4file.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4grp.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4type.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4var.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/ncfunc.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4internal.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4hdf.c netcdf_src_SOURCES:INTERNAL=/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/string.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/v1hpg.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/onstack.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/rnd.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/utf8proc.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/utf8proc_data.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nclistmgr.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/putget.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/attr.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nc3dispatch.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nc.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/var.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/dim.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/ncx.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/ncx.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/lookup3.c;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/pstdint.h;/home/deepaksurti/pisi/tmp/VTK-6.1.0-1/work/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/posixio.c -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeError.log Type: application/octet-stream Size: 126098 bytes Desc: not available URL: