[Insight-developers] proposal: remove the gdcm build options from ITK

Alexandre GOUAILLARD agouaillard at gmail.com
Sat Mar 12 16:01:11 EST 2011 

mark,

The latest itk v4 pulled form git has the itkGDCM tests (see below).
You mentioned that those tests were not present since modularization,
but I find trace of a feb 9th merge of a feb 5th commit that seems to
indicate the support was taken care of:

Merge topic 'ModularizationFixingGDCMTestDriver'
55c0f87 ENH: Use IO test driver for GDCM IO tests.

I also confirmed that the gdcm cmake variables you mentioned (as well
as direct gdcm wrapping variables) where present before and are still
present. I did not turn them ON to test (yet).

I agree with you that if they are of no use for ITK, they should not
be visible when using the itk copy of gdcm.

Perhaps the gdcm community would like to comment on this?

alex.

ld: warning: duplicate dylib ../../../../lib/libITK-Path-4.0.1.dylib
ld: warning: duplicate dylib ../../../../lib/libITK-Transform-4.0.1.dylib
ld: warning: duplicate dylib ../../../../lib/libITK-Statistics-4.0.1.dylib
ld: warning: duplicate dylib ../../../../lib/libITK-Common-4.0.1.dylib
[100%] Built target ITK-IntegratedTestTestDriver
NB8086:BUILD-DEBUG-64 gouaillarda$ ctest -R GDCM
Test project /Users/gouaillarda/DEVEL/GITROOT/ITK/BUILD-DEBUG-64
    Start 645: itkGDCMImageIOTest1
1/8 Test #645: itkGDCMImageIOTest1 ..................   Passed    2.45 sec
    Start 646: itkGDCMImageIOTest2
2/8 Test #646: itkGDCMImageIOTest2 ..................   Passed    0.38 sec
    Start 647: itkGDCMImageIOTest3
3/8 Test #647: itkGDCMImageIOTest3 ..................   Passed    0.28 sec
    Start 648: itkGDCMImageIOTest4
4/8 Test #648: itkGDCMImageIOTest4 ..................   Passed    0.20 sec
    Start 649: itkGDCMImageIOTest5
5/8 Test #649: itkGDCMImageIOTest5 ..................   Passed    0.37 sec
    Start 650: itkGDCMSeriesReadImageWrite
6/8 Test #650: itkGDCMSeriesReadImageWrite ..........   Passed    0.33 sec
    Start 651: itkGDCMSeriesStreamReadImageWrite1
7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ...   Passed    0.28 sec
    Start 652: itkGDCMSeriesStreamReadImageWrite2
8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ...   Passed    0.25 sec

100% tests passed, 0 tests failed out of 8

Label Time Summary:
ITK-IntegratedTest    =   4.55 sec

Total Test time (real) =   6.32 sec
NB8086:BUILD-DEBUG-64 gouaillarda$



On Sun, Mar 13, 2011 at 2:13 AM, Mark Roden <mmroden at gmail.com> wrote:
> I assumed as much, but I wanted to be sure.  There could have been the
> intent to push all gdcm tests into gdcm proper.  And as I said, there
> are none of the standard gdcm tests in itk now, nor were they there
> prior to the merge, so if that was the intent, I just need to know so
> that I can put them there.
>
> Mark
>
> On Sat, Mar 12, 2011 at 9:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I think the itkGDCM tests should definitely stay. I assume that their
>> absence after modularization is not intentional.
>>
>> Bill
>>
>> On Sat, Mar 12, 2011 at 10:29 AM, Alexandre GOUAILLARD
>> <agouaillard at gmail.com> wrote:
>>> hi
>>>
>>> On Sat, Mar 12, 2011 at 2:55 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Previously, there were itk-gdcm specific tests, that could be run by typing
>>>>
>>>> ctest -R itkGDCM
>>>>
>>>> Those tests are no longer present since modularization.  I do not know
>>>> if they have been removed because they don't match the expectations of
>>>> the new scheme, or as an oversight, or if the gdcm_build_tests cmake
>>>> flag was supposed to cover it.  I'm putting this discussion on the
>>>> insight developers list as a result, so that perhaps I can get some
>>>> feedback on that.
>>>
>>> I'm checking that right now.
>>>
>>>>
>>>> Personally, I think that we should just have the itk gdcm tests back,
>>>> and not have the same coverage as the rest of gdcm.  ITK devs, at
>>>> least for the moment, don't need a complete tag editing solution, they
>>>> need to be able to read and write various forms of image data.  I'm
>>>> fairly certain that the previous test suite covered those cases.
>>>>
>>>
>>> We have to be positive.
>>>
>>>> The testing data size is a few megs, so not a big deal, and it's
>>>> retrieved through a git submodule init call in the gdcm root
>>>> directory.  That is a bit of a pain for deployment purposes, because
>>>> it means that any user who wants to use gdcm has to get a particular
>>>> set of images for testing, and they have to use a series of
>>>> non-obvious steps to get those images and set up the testing directory
>>>> (which is, as I said, currently blank).  I suppose that could be done
>>>> through the setupfordevelopment script, but that seems like overkill,
>>>> especially if the older itkgdcm tests did the job.
>>>>
>>>
>>> That sounds good, the actual testing/data is also retrieved thourgh a
>>> git submodule mechanism, so I guess, if we were to decide to take in
>>> the gdcm tests, there is no show stopper. We need to investigate if
>>> that s really what we want / need to do. i.e. we need to have a list
>>> of gdcm features available in ITK proper.
>>>
>>> alex.
>>>
>>>> Mark
>>>>
>>>> On Fri, Mar 11, 2011 at 10:35 PM, Alex Gouaillard <agouaillard at gmail.com> wrote:
>>>>> Hi mark.
>>>>>
>>>>>> it would be good to know how these tests worked in the
>>>>>> past.
>>>>>
>>>>> Your job to find out.
>>>>>
>>>>> Then if those tests were not included, please answer the following questions first:
>>>>> - are those testing gdcm features exposed in itk ? If not, no need in itk proper.
>>>>> - what is the size of the testing data?
>>>>> - how do you get the data? (cvs? Svn? Tarball?...)
>>>>>
>>>>> Gaetan, can you then advice on using external project Thingy from cmake 2.8 ?
>>>>>
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> 2011/3/11 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>>>>>>>
>>>>>>> Le 12 mars 11 à 01:04, Mark Roden a écrit :
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> So I notice that under the new (and the old, incidentally) cmake
>>>>>>>> options for itk, there are the four canonical gdcm options, namely:
>>>>>>>>
>>>>>>>> build_applications
>>>>>>>> build_examples
>>>>>>>> build_shared_libs
>>>>>>>> build_testing
>>>>>>>>
>>>>>>>> However, since the gdcm stuff is supposed to be rolled in directly
>>>>>>>> with ITK, these options don't make a whole lot of sense to me.
>>>>>>>> Indeed, choosing build_testing as an option leads to cmake errors
>>>>>>>> which, when solved, lead to many compilation errors when testing is
>>>>>>>> turned on.
>>>>>>>>
>>>>>>>> I propose to remove these options from the build process entirely.
>>>>>>>> The user isn't interested in gdcm per se, but in having dicom support
>>>>>>>> in itk.  That means that these options are not useful to the user, and
>>>>>>>> can only cause building problems.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> I'd keep the tests, and turn them on automatically when ITK's option
>>>>>>> BUILD_TESTING is on. I don't think you will reimplement all the gdcm tests
>>>>>>> in ITK, so it would be nice that gdcm can be tested on the user system with
>>>>>>> the other ITK tests.
>>>>>>> This wouldn't be the only case: VXL tests are run with the ITK tests for
>>>>>>> example.
>>>>>>>
>>>>>>> Gaëtan
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Gaëtan Lehmann
>>>>>>> Biologie du Développement et de la Reproduction
>>>>>>> INRA de Jouy-en-Josas (France)
>>>>>>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>>>>>>> http://voxel.jouy.inra.fr  http://www.itk.org
>>>>>>> http://www.mandriva.org  http://www.bepo.fr
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>

More information about the Insight-developers mailing list