[Insight-developers] NrrdIO vs non-NrrdIO code

[Michel Audette]

Hi Gordon,

I think that we're close to wrapping this up now, except for this file
formatVTK.c, which has a few calls to non-NrrdIO functions.

Other than that, I've submitted experimental ctests on Linux,
cross-compiled Mac such as Brad's, and Windows.
http://www.cdash.org/CDash/viewTest.php?onlypassed&buildid=535061
http://www.cdash.org/CDash/viewTest.php?onlypassed&buildid=535075
http://www.cdash.org/CDash/viewTest.php?onlypassed&buildid=535078
all of which went well.

Please feel free to comment.

Best wishes,

Michel


On Mon, Feb 8, 2010 at 12:39 PM, Michel Audette
<michel.audette at kitware.com> wrote:
> Hi Gordon,
>
> in conjunction with the integration of the latest NrrdIO code in the
> Sourceforge repository into ITK, I've been seeing come code in the
> relevant libraries: namely in air, that was labeled non-NrrdIO,
> typically labeled
> /* ---- BEGIN non-NrrdIO */
> ...
> /* ---- END non-NrrdIO */
> which we elected not to include in this integration. I'm finding that
> this categorization is not air-tight, so we should discuss how to
> proceed further.
>
> Specifically, formatVTK.c has no area that is labeled non-NrrdIO, but
> _nrrdFormatVTK_write(FILE *file, const Nrrd *_nrrd, NrrdIoState *nio)
> invokes
>  airSrandMT(AIR_CAST(unsigned int, airTime()));
> in line 380, and both airSrandMT() and  airTime() fall into non-NrrdIO
> sections.
>
> Should all of the relevant source and header files, as listed in the
> wiki http://www.itk.org/Wiki/Proposals:Updating_Nrrd_library_2009  be
> committed in their entirety instead? If we elect to proceed as we have
> been by excluding non-NrrdIO code, is it advisable to revert back to
> old ITK versions, or can you suggest an alternate option?
>
> Thanks for your kind support.
>
> Best wishes,
>
> Michel
>
> --
> Michel Audette, Ph.D.
> R & D Engineer,
> Kitware Inc.,
> Chapel Hill, N.C.
>



-- 
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.