[ITK] "Can We Trust the Libraries We Use?", i.e. "You've got JPEG"

Matt McCormick matt.mccormick at kitware.com
Tue Aug 12 00:04:47 EDT 2014


Michka, Ho, and Ben pointed out a very good blog post that looked at
the output of a static code analysis tool on ITK and the third party
libraries that it uses:

  http://www.viva64.com/en/b/0271/


The post brings up admirable principles, namely:

1) Use automated code quality tools.
2) Avoid duplication of effort and improve overall excellence by using
open source libraries.
3) Reduce maintenance costs by pushing fixes upstream.


ITK has strong practices in these areas and is continuously making
improvements.  In particular,

1) The cross-platform continuous testing on the software quality
dashboard [1] has long been a strong suit [1]. On the dashboard we
configure, build, and test, but we also run valgrind dynamic memory
analysis and gcov coverage testing.  The latter are available on CDash
and also posted to Bill L's website [2].

We also have Coverity static analysis [3].  Following Bill H's setup
instructions, Sean and Kent's posts to the list, I will also be
setting up scan-build static analysis [4].

[1] http://open.cdash.org/index.php?project=Insight

[2] http://lorensen.github.io/VTKCodeCoverage/ITK/index.html

[3] https://scan.coverity.com/projects/783

[4] http://clang-analyzer.llvm.org/scan-build.html


2)  ITK uses a number of excellent ThirdParty open source libraries,
found in the Modules/ThirdParty directory.  We are continually
improving our CMake configuration to support additional
ITK_USE_SYSTEM_<library> so native system libraries can be utilized.
For example, in the last four releases, for example, we have improved
support for [1]

* ITK_USE_SYSTEM_VXL
* ITK_USE_SYSTEM_TIFF
* ITK_USE_SYSTEM_EXPAT
* ITK_USE_SYSTEM_DCMTK
* ITK_USE_SYSTEM_HDF5

[1] http://www.itk.org/Wiki/ITK/Releases


3) We are always trying to improve our efforts to push fixes upstream
and stay in sync with upstream.  Recently, a big step forward in this
area has been led by Brad King and Brian Helba, who have improved and
generalized a process to perform git subtree merges of third party
libraries [1].

This technical improvement to version management of third party
libraries allows us to stay in sync with upstream, push patches
upstream, and ensure upstream and our patches pushed upstream retain
proper credit.  This method is applied to a number of third party
libraries in the tree, and we are incrementally adding more.  A few
that are admittedly in great need of updates, as noted in the article,
are OpenJPEG and GDCM.

[1] http://review.source.kitware.com/#/c/14175/


All contributions to these efforts are welcome!


On a side note, the issues brought up have been addressed in the
following patches:

  http://review.source.kitware.com/#/c/16617/
  http://review.source.kitware.com/#/c/16623/
  http://review.source.kitware.com/#/c/16626/
  http://review.source.kitware.com/#/c/16627/
  http://review.source.kitware.com/#/c/16624/
  http://review.source.kitware.com/#/c/16628/
  http://review.source.kitware.com/#/c/16629/


More information about the Community mailing list