# Software process updates
**URL:** https://discourse.kitware.com/t/software-process-updates/113
**Category:** Software Process
**Created:** [May 25, 2018, 10:13pm UTC](https://discourse.kitware.com/t/software-process-updates/113 "2018-05-25T22:13:14Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 25, 2018, 10:13pm UTC](https://discourse.kitware.com/t/software-process-updates/113/1 "2018-05-25T22:13:16Z")
The smtk/cmb dashboards have not seen a lot of love in the past few months, so I’m spending a little time getting them back up and glowing green. In the process, I have made a few changes to CMB’s build process:
1. Bump boost to 1.66
- This change was needed to support msvc2017, which is on my list of things to implement
- A side effect of this update is that we now require the latest version of cmake. Moho has been updated and deployed (thus it is currently the only buildbot that successfully builds). [Kerbin](https://kwgitlab.kitware.com/buildbot/buildbot/merge_requests/1468), [TalosIV, Junction and Praxis](https://kwgitlab.kitware.com/buildbot/buildbot/merge_requests/1469) will be updated shortly (and their dashboards will be broken until then).
1. Remove smtk’s custom rtvl in favor of the version in vxl master
- rtvl doesn’t have the quietest build, and we were supporting an independent (and outdated) fork of it because of a few features that were added but never accepted back into the main fork. I have [factored out the changed code and put it in smtk’s vxl extension](https://gitlab.kitware.com/cmb/smtk/commit/c81b92e325716d05cf1a30a663b36216141a225c).
- The rest of our rtvl was compatible with the upstream version, so I [removed our version from thirdparty](https://gitlab.kitware.com/cmb/smtk/commit/2691525445c35dbcdc74a480c69ebc7a2b9ed55e).
- It looks as though our build permutation for VXL is not tested, because it did not work out of the box. I am working on updating VXL’s master ([here](https://github.com/vxl/vxl/pull/484), [here](https://github.com/vxl/vxl/pull/485) and [here](https://github.com/vxl/vxl/pull/486)); when these changes land, we can switch cmb superbuild’s VXL repository from my fork back to the main fork.
The next steps include
1. Update ParaView to the latest master
- @dcthomp and @Bob_Obara have made changes to ParaView master (does anyone have links to these MRs?) that we would like to see in CMB
1. Move some (all?) of the dashboard machines to Qt 5.11
2. MSVC2017 testing on Kerbin?
3. Superbuild for development?
- Our superbuild is currently a pain point for external contributors
- Marcus wrote an [interesting blog post](https://blog.kitware.com/cmake-superbuilds-git-submodules/) about the different types of superbuilds he’s maintained, and one of them that caught my eye was a “developer build” designed to bootstrap a developer’s environment.
- If Marcus creates a developer superbuild for TomViz (and I believe he means to), we could get most of the infrastructure for CMB’s developer superbuild for free.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [May 25, 2018, 10:38pm UTC](https://discourse.kitware.com/t/software-process-updates/113/2 "2018-05-25T22:38:02Z")
@tj.corona My [PV MR](https://gitlab.kitware.com/paraview/paraview/merge_requests/2477) made it in today. It should fix the “Could not locate server on which the source is being added” error message.
I am all for a “developer” superbuild, but we also need to generate packages. I would prefer to generate packages that have a chance at being included in system distribution channels (fedora, ubuntu, homebrew, chocolatey/nuget), as that also reduces the demand for developer superbuilds and one-off customer packaging. But all of these things cost time.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 26, 2018, 12:15pm UTC](https://discourse.kitware.com/t/software-process-updates/113/3 "2018-05-26T12:15:37Z")
> [@dcthomp](#):
>
> I would prefer to generate packages that have a chance at being included in system distribution channels (fedora, ubuntu, homebrew, chocolatey/nuget), as that also reduces the demand for developer superbuilds and one-off customer packaging.
That would be ideal!
> [@dcthomp](#):
>
> But all of these things cost time.
This is why I would only pursue a developer superbuild if there were already a workable template (e.g. TomViz) to use.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 26, 2018, 12:22pm UTC](https://discourse.kitware.com/t/software-process-updates/113/4 "2018-05-26T12:22:07Z")
This past March, VTK’s `vtkGDALRasterReader` API was modified to remove `GetNumberOfPoints()`. Oddly, it was replaced with `GetNumberOfCells()`, which looks like it returns the same integral value. [This MR](https://gitlab.kitware.com/cmb/smtk/merge_requests/1121) updates smtk to use the new function call, but I need confirmation that this is a logically sane change. If this is still up in the air next week, I can ask the VTK developer who made the changes for his input.
(Edit) I am including this here because it will most likely come up when we update ParaView (it is currently breaking the VTK-only build).
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [May 26, 2018, 12:32pm UTC](https://discourse.kitware.com/t/software-process-updates/113/5 "2018-05-26T12:32:45Z")
> [@tj.corona](#):
>
> This past March, VTK’s vtkGDALRasterReader API was modified to remove GetNumberOfPoints(). Oddly, it was replaced with GetNumberOfCells(),
Looking at the commit, it switched the reader to use the dual of the original grid (i.e., instead of reporting an image data with values at corner points, it returns a grid with values at the same set of locations but now they are cell centers rather than corner points. Depending on how you use the reader’s output, your solution may or may not be correct. If it’s not, you can run a cell-to-points filter on the reader’s output to get point-data. If you look at the changes to `TestGDALRasterReader.cxx` in the same commit (646b2dedba4…19b695dedb), you’ll see how they use `vtkCellDataToPointData`.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 26, 2018, 12:36pm UTC](https://discourse.kitware.com/t/software-process-updates/113/6 "2018-05-26T12:36:41Z")
I suppose that our use of the reader hasn’t changed, so an implicit conversion from cell-centered to point-centered data for our use case shouldn’t hurt.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [May 26, 2018, 12:40pm UTC](https://discourse.kitware.com/t/software-process-updates/113/7 "2018-05-26T12:40:37Z")
Are we fetching the point-data directly and using it? Or are we using the dataset to interpolate values? The interpolation will be different now (cell-data is constant over the entire cell while point-data varies (bi-/tri-)linearly. If the latter, we should explicitly run `vtkCellDataToPointData`. If the former, your change is fine although perhaps a little confusing to future developers (or yourself if your memory is anything like mine 🙂 ).
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 26, 2018, 12:52pm UTC](https://discourse.kitware.com/t/software-process-updates/113/8 "2018-05-26T12:52:54Z")
> [@dcthomp](#):
>
> Are we fetching the point-data directly and using it? Or are we using the dataset to interpolate values?
Ok, after some digging: `vtkGDALRasterPolydataWrapper` is pv-wrapped as a converter from GDAL to point cloud data (so no testing on the master branch). The implementation iterates over the extent of the `vtkImageData` and for each location it computes the point ID and extracts the the scalar value for that point.
It looks like we will need to convert from cell data to point data before performing this step. I will update the MR accordingly.
(Edit) I’m having a slow morning. We don’t need to convert the data. I’ll make the appropriate changes to the MR just now.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 29, 2018, 12:38pm UTC](https://discourse.kitware.com/t/software-process-updates/113/9 "2018-05-29T12:38:55Z")
The fix to `vtkGdalRasterPolydataWrapper` can be found [here](https://gitlab.kitware.com/cmb/smtk/merge_requests/1121#note_415365). I’m holding off on merging until it can be paired with the ParaView update.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [May 29, 2018, 12:39pm UTC](https://discourse.kitware.com/t/software-process-updates/113/10 "2018-05-29T12:39:56Z")
My PRs to VXL have been accepted into the master branch, so we can now start tracking the main fork of VXL. A MR to make this change in our superbuild can be found [here](https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/428).