[Insight-developers] proposal: remove the gdcm build options from ITK
Mark Roden
mmroden at gmail.com
Sat Mar 12 23:21:09 EST 2011
Well, the fix may be there in the repository, but when I run:
Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R itkGDCM
Test project /Users/mmroden/Documents/src/itk/itk-build-unix
No tests were found!!!
Or with just gdcm:
Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
Test project /Users/mmroden/Documents/src/itk/itk-build-unix
No tests were found!!!
This is after turning everything on in CMake syncing 2 days ago. I
then synced 20 minutes ago:
Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
Test project /Users/mmroden/Documents/src/itk/itk-build-unix
Start 645: itkGDCMImageIOTest1
1/8 Test #645: itkGDCMImageIOTest1 .................. Passed 1.30 sec
Start 646: itkGDCMImageIOTest2
2/8 Test #646: itkGDCMImageIOTest2 .................. Passed 0.31 sec
Start 647: itkGDCMImageIOTest3
3/8 Test #647: itkGDCMImageIOTest3 .................. Passed 0.19 sec
Start 648: itkGDCMImageIOTest4
4/8 Test #648: itkGDCMImageIOTest4 .................. Passed 0.16 sec
Start 649: itkGDCMImageIOTest5
5/8 Test #649: itkGDCMImageIOTest5 .................. Passed 0.30 sec
Start 650: itkGDCMSeriesReadImageWrite
6/8 Test #650: itkGDCMSeriesReadImageWrite .......... Passed 0.26 sec
Start 651: itkGDCMSeriesStreamReadImageWrite1
7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ... Passed 0.19 sec
Start 652: itkGDCMSeriesStreamReadImageWrite2
8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ... Passed 0.19 sec
100% tests passed, 0 tests failed out of 8
Label Time Summary:
ITK-IntegratedTest = 2.90 sec
Total Test time (real) = 6.38 sec
So either I didn't build everything right the first time, or I didn't
have the gdcm tests.
I think that these tests only cover a subset of gdcm functionality;
the question is, what kind of functionality are we going to need to
add in?
Mark
On Sat, Mar 12, 2011 at 1:01 PM, Alexandre GOUAILLARD
<agouaillard at gmail.com> wrote:
> 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